On Wed, Jul 21, 2010 at 3:49 AM, Philip Jägenstedt <[email protected]>wrote:
> On Wed, 21 Jul 2010 00:20:37 +0200, Paul Ellis <[email protected]> > wrote: > > Any solution that requires creating another window and opening a new >> document would create a lot of issues that would not compare favorably >> with >> any current popular web video plugin (Flash, Silverlight, etc). It would >> not >> be a very seemless transition. The <video> resource from the parent page >> may >> have downloaded hundreds of MB of data and then the new window would make >> a >> new separate request for the same resource. Certainly the browsers could >> try >> to aggressively cache video content for these situations but even that >> wouldn't work in all cases (any HTTP connection that doesn't allow byte >> range requests, e.g. HTTP 1.0), and it probably would not work very well >> for >> resource constrained devices such as smartphones and tablets. This type of >> hand-off would have to happen every time the user switched between >> fullscreen and embedded mode as well. >> > > Browsers can and do cache resources that don't support byte ranges. About > the topic at hand, I think the experience we want is to click a button or > select "fullscreen" in the context menu, causing an element to go to > fullscreen, still with the possibility of rendering some content on top of > it, for custom controls and the like. > I suppose I wasn't clear in what I meant. Clearly browsers can cache resources that don't support byte ranges. I was pointing out that if a new connection is made for a resource that has previously only been partially downloaded/cached, then the browser would not be able to resume the download. It must start downloading the resource from the beginning. Paul Ellis
