W3C home > Mailing lists > Public > public-html-comments@w3.org > July 2010

Re: Fulscreen Tag Proposal

From: Philip Jägenstedt <philipj@opera.com>
Date: Wed, 21 Jul 2010 20:45:24 +0200
To: "Paul Ellis" <paul@ellisfoundation.com>
Cc: "Ron Reiter" <ron.reiter@gmail.com>, "Daniel Hendrycks" <kondo8@hotmail.com>, "public-html-comments@w3.org" <public-html-comments@w3.org>
Message-ID: <op.vf7idyz4atwj1d@philip-pc.gothenburg.osa>
On Wed, 21 Jul 2010 20:22:44 +0200, Paul Ellis <paul@ellisfoundation.com>  
wrote:

> On Wed, Jul 21, 2010 at 3:49 AM, Philip Jägenstedt  
> <philipj@opera.com>wrote:
>
>> On Wed, 21 Jul 2010 00:20:37 +0200, Paul Ellis  
>> <paul@ellisfoundation.com>
>> 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.

This also isn't the case, we can and do cache just part of the resource  
and reuse that as long as it stays in the cache. I don't know what other  
browsers do.

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 21 July 2010 18:46:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:14:04 GMT