cpearce at mozilla.com
Sun Oct 16 15:52:07 PDT 2011
On 15/10/2011 5:27 p.m., Anne van Kesteren wrote:
> I wrote up a draft:
Thanks for writing this up.
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
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
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().
> 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.
More information about the whatwg