[whatwg] Fullscreen Update

[Silvia Pfeiffer]

On 19/10/2011, at 6:36 PM, Darin Fisher <darin at chromium.org> wrote:

> On Tue, Oct 18, 2011 at 9:40 PM, Anne van Kesteren <annevk at opera.com> wrote:
> 
>> 1) How much should UI-based and API-based fullscreen interact? To me it
>> seems nice if pressing F11 would also give you fullscreenchange events and
>> that Document.fullscreen would yield true. Why would you not want to give
>> the same presentation via native activation and API-based activation? Of
>> course when you activate it UI-wise, navigation should not exit it. For
>> native <video> controls the case seems clearer that they should work using
>> this API.
>> 
> 
> Agreed.  What should the target be for the fullscreenchange events in the
> native activation case?  Should it be the documentElement or perhaps the
> window?  Since the fullscreen attribute exists on Document instead of
> Window, it seems like it might be odd to dispatch the fullscreenchange event
> to the window.  However, in the native activation case, you could really
> argue that it is the window that is being presented fullscreen and not the
> document since fullscreen survives navigation.
> 
> 
> 
>> 
>> 
>> 2) Chris brought forward the case of nesting. You have a fullscreen
>> presentation (lets assume API-based activated for now) and in that
>> presentation there's some video that the presenter wants to display
>> fullscreen (lets assume the video player is a custom widget with API-based
>> fullscreen activation for now). Once the presenter exits displaying the
>> video fullscreen, the presentation should still be fullscreen.
>> 
>> Initially this was brought up with the video being hosted in a separate
>> descendant document, but the video could be in the same document as well.
>> roc suggested a model that works when you have separate documents and it
>> could be made to work for the single document case too, as long as the level
>> of nesting remains is no larger than required for the presentation scenario
>> mentioned above.
>> 
>> Is that an acceptable limitation? Alternatively we could postpone the
>> nested fullscreen scenario for now (i.e. make requestFullscreen fail if
>> already fullscreen).
>> 
> 
> +1 for punting on the nested case.


I think you'd ever only want to have one thing fullscreen at a time. Thus, if you go from a fullscreen to another, the previous one should naturally leave fullscreen. I think that's how presentation functionality works on ppt and similar tools, too.

Silvia.