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.
