W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2011

[whatwg] Fullscreen Update

From: Chris Pearce <cpearce@mozilla.com>
Date: Thu, 20 Oct 2011 14:20:57 +1300
Message-ID: <4E9F7779.3090601@mozilla.com>
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.

>
> 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.

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.

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.

> 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.

>
> 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.

Chris Pearce.
Received on Wednesday, 19 October 2011 18:20:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:37 UTC