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

[whatwg] Fullscreen

From: Chris Pearce <cpearce@mozilla.com>
Date: Mon, 17 Oct 2011 11:52:07 +1300
Message-ID: <4E9B6017.90704@mozilla.com>
On 15/10/2011 5:27 p.m., Anne van Kesteren wrote:
> I wrote up a draft:
>
> http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html

Thanks for writing this up.

Comments:

 1. We should define what happens when the full-screen element is
    removed from a document. Roc and I thought it would be best to *not*
    reset the full-screen elements, :fullscreen, and
    :fullscreen-ancestor styles in ancestor documents, so that the
    current document's frame remains in full-screen mode. i.e. removing
    the full-screen element should result in the same state as if  you
    requested full-screen on said element when it was not in a document.
    The fullscreen state needs to be reset in descendent documents though.
 2. We should define what happens when the full-screen element is
    removed from a document and inserted into another document. I think
    we should reset the fullscreen element in the old fullscreen
    element's owner's doc, and reset all fullscreen state (flag and
    pseudo classes) in all the old owner document's descendent
    documents, but not in its ancestor documents. So this should be
    equivalent to requesting full-screen on an element, and releasing
    all references to that element (though arguably
    Document.fullscreenElement would keep that element alive in that
    case...).
 3. Step 3.6 of the "transition to fullscreen" algorithm fires a
    fullscreenchange event to the document which requests fullscreen,
    regardless of whether it was already in fullscreen mode or not, and
    regardless of whether the fullscreen element changed. If a doc is
    already in fullscreen state, requesting fullscreen again may change
    the fullscreen element, but won't change the document.fullscreen
    flag. My thoughts are we should dispatch fullscreenchange in any
    document in the doc tree whenever document.fullscreen changes, or
    whenever the document.fullscreenElement changes (so that script
    knows if the request to change the fullscreen element was granted).
 4. The "transition to fullscreen" algorithm needs to reset the
    full-screen state on all documents in the doctree, otherwise
    requesting full-screen on a node in a sibling/cousin document to the
    current fullscreen element's document will end up with inconsistent
    state. Also if a request for full-screen originates in a
    sibling/cousin document to the current full-screen element's
    document, resetting the fullscreen state in the documents in the
    sibling/cousin branch should cause  fullscreenchange events to be
    dispatched to those documents. The order in which fullscreenchange
    events are dispatched should be defined (i.e. do the
    fullscreenchange events for documents exiting fullscreen run before
    or after the fullscreenchange events for documents entering
    fullscreen?).
 5. The "transition from fullscreen" algorithm only fires the
    fullscreenchange event at the document which requests the fullscreen
    exit, not all the documents whose fullscreen state changes upon the
    exit of fullscreen (ancestor and descendent documents).
 6. We should dispatch a fullscreendenied event if the request for
    fullscreen is denied. Feedback from authors is that it is critical
    to know whether a request for fullscreen has been denied, so that
    they can fallback to other mechanisms. Mozilla's original proposal
    intentionally didn't include this because we thought we'd require
    permission to enter fullscreen. We've since changed to an "ask
    forgiveness" model, where the request to go fullscreen can be made
    synchronously, so the previous criticisms against this event don't
    apply. Without this event, if there is an animation for enter full
    screen, there's no way to distinguish between "entered full-screen
    but running animation" and the "fullscreen denied case", other than
    by setting a timeout of appropriate length, which is hacky.
 7. I prefer "requestFullScreen()" for the same reason Olli gave.
    Especially if we make Element.requestFullScreen() asynchronous;
    enterFullScreen() really does imply synchronous action. I prefer
    exitFullscreen() to cancelFullScreen().


Regards,
Chris Pearce.

>
> Defining when exactly the "fullscreen enabled" flag is set for 
> Document objects I will leave up to HTML. As well as defining the 
> "allowfullscreen" attribute. Presumably it should be set for Document 
> objects associated with the top-level browsing context and descendant 
> browsing context as long as their browsing context container has the 
> aforementioned attribute set.
>
> If we want to transition from fullscreen when navigating, HTML can 
> define that as well, neatly integrated in the navigation section. The 
> "Model" section of the Fullscreen specification has an appropriate hook.
>
>
> I have not added the key restrictions given earlier emails. 
> Unfortunately there was not that much feedback on them, but maybe this 
> draft will help on that front!
>
>
> I went with "fullscreen" rather than "full screen" as that seemed 
> cleaner and easier to type. I also used "enter" and "exit" rather than 
> "request" and "cancel" as they seemed somewhat nicer too. I'm less 
> attached to this latter change though.
>
>
Received on Sunday, 16 October 2011 15:52:07 UTC

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