On Thu, 20 Oct 2011 10:20:57 +0900, Chris Pearce <cpea...@mozilla.com>
wrote:
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.
Except that the root element is special cased and will — as far as the end
user is concerned — give the exact same visual effect as F11 fullscreen.
So what you are saying is not true, unless we remove the special case for
the root element, which might be a good idea.
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.
That sounds like a pretty bad solution to me. It also fails for
encapsulated cross-origin bindings (which are somewhat likely to arrive to
the platform in due course).
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.
It does not sound that great to me. Maybe the presentation case would
instead be solved by just letting the page enlarge the video itself.
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.
I think keeping it simple argues for the following:
* Only allow a single element to go fullscreen
* If an element is already fullscreen dispatch fullscreenerror
* Not special case the root element
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.
I think I agree more with Darin Fisher and James Graham.
--
Anne van Kesteren
http://annevankesteren.nl/
