- From: Chris Pearce <cpearce@mozilla.com>
- Date: Mon, 17 Oct 2011 11:52:07 +1300
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