[whatwg] Fullscreen Update

[Anne van Kesteren]

On Thu, 20 Oct 2011 10:20:57 +0900, Chris Pearce <cpearce at mozilla.com>  
wrote:
> On 19/10/2011 5:40 p.m., Anne van Kesteren 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.
>
> These modes cover different cases. F11 fullscreen mode is when the user
> wants to hide their browser user interface, but otherwise doesn't want
> to affect presentation. Whereas the fullscreen API is to allow sites to
> make a specific element the fullscreen element.

Except that the root element is special cased and will — as far as the end  
user is concerned — give the exact same visual effect as F11 fullscreen.  
So what you are saying is not true, unless we remove the special case for  
the root element, which might be a good idea.


> In this presentation-video case, if the video is in the same document or
> in a same-origin subdocument, the page can script switching full-screen
> between the "main" full-screen element and the video element and vice
> versa (provided Element.requestFullScreen() while in fullscreen switches
> the fullscreen element). So custom controls on the video element could
> be implemented to solve this problem in the single document and in the
> non-cross origin multi-document case.

That sounds like a pretty bad solution to me. It also fails for  
encapsulated cross-origin bindings (which are somewhat likely to arrive to  
the platform in due course).


> In the cross origin multi-document case, if document.exitFullScreen()
> causes all documents to exit full-screen (not just the target document
> and its descendents) it would also be pretty easy for the parent
> document to listen for the fullscreenchange event when the video exited,
> the and show its button for the main document to re-enter fullscreen. It
> would be a 2-click process to fullscreen change from the video back to
> the main document, but no big drama really.

It does not sound that great to me. Maybe the presentation case would  
instead be solved by just letting the page enlarge the video itself.


>> 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.
>
> We could go with Roc's suggestion and provided requestFullScreen()
> switches fullscreen mode we'd be ok, but I think that would complicate
> the API a bit much. Seems better to keep it simple.

I think keeping it simple argues for the following:

* Only allow a single element to go fullscreen
* If an element is already fullscreen dispatch fullscreenerror
* Not special case the root element


>> Is that an acceptable limitation? Alternatively we could postpone the
>> nested fullscreen scenario for now (i.e. make requestFullscreen fail
>> if already fullscreen).
>
> I think we should:
>
>  1. Make Element.requestFullScreen() switch the fullscreen element (so
>     we can handle the single document and same-origin documents cases)
>     when called while any document is in fullscreen mode, and
>  2. make document.exitFullScreen() exit all documents from fullscreen.
>     It keeps the API simple, and provided we fire fullscreenchange
>     events whenever a documents fullscreen attribute changes, pages can
>     detect this and provide buttons to restore the user to their desired
>     fullscreen state.

I think I agree more with Darin Fisher and James Graham.


-- 
Anne van Kesteren
http://annevankesteren.nl/