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 21:46:45 +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.vf7k77ezatwj1d@philip-pc.gothenburg.osa>
On Wed, 21 Jul 2010 21:01:08 +0200, Paul Ellis <paul@ellisfoundation.com>  
wrote:

> On Wed, Jul 21, 2010 at 11:45 AM, Philip Jägenstedt  
> <philipj@opera.com>wrote:
>
>> 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.
>
>
> You could still use the cached portion, but to get beyond the partially
> cached portion the browser will have to re-download all of the data that  
> has
> already been cached. So if a video has previously been 50%  
> downloaded/cached
> and a new request is made for that video to resume playback at 50% of the
> way into the video then the the only way the video can resume playback  
> is to
> start a download from the beginning of the file.

Right, for a server that doesn't support byte ranges, that's what will  
happen.

> I know that it would seem like an edge case that sites would want to  
> stream
> video using HTTP 1.0 or with range requests disabled but it has been my
> experience working on the DivX Web Player that it is much more common  
> than
> you would expect. The direction being proposed in the Mozilla wiki for
> fullscreen would work fine in this scenario. My comments were directed at
> the original post in this thread.

OK, let's leave it at that :)

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 21 July 2010 19:47:29 GMT

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