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.
