Re: [whatwg] [fullscreen] cancelFullScreen()
On 13/10/2011 5:23 p.m., Anne van Kesteren wrote: On Thu, 13 Oct 2011 11:26:20 +0900, Chris Pearce cpea...@mozilla.com wrote: On 12/10/2011 10:35 p.m., Anne van Kesteren wrote: Is cancelFullScreen() synchronous or should it queue a task? Synchronous, so that Document.fullScreen immediately reflects the state change? Why would it need to be asynchronous? Is the event dispatched synchronously as well then? I was thinking that maybe you want to trigger an animation here of some kind. Though I suppose that could be done synchronously as well. It would also be nice if the page can keep rendering and running JS while the animation is running. Asynchronous dispatch would allow that. Also ideally you'd want to dispatch the event after the animation is complete, so that the size of the document's view port is stable; if you dispatched the event before your animation is complete, the full-screen element's dimensions may not have reached the viewport size, and content might get confused, or at worst inconvenienced. If you invoke cancelFullScreen() on a Document of a parent or child browsing context from the browsing context in whose Document requestFullScreen() was invoked it should presumably still work, no? The parent of a Document which is in full-screen will also be in full-screen mode. So if cancelFullScreen() is invoked in the parent Document, it should exit full-screen in the parent. I interpreted the spec to mean if one full-screen document cancels full-screen, all documents in the tree exit full-screen mode. I too have been wondering if we should honour calls to cancelFullScreen() in a non-full-screen child Document of the Document which requested full-screen. It seems to me that being fullscreen is a property of the top-level browsing context. All that is potentially associated with a document is the fullscreen element. If you have a document A with two sub-documents B and C, it does not make much sense to me that if you go fullscreen from B, C would not report as being fullscreen. I mean sure, there is no fullscreen element but it is definitely rendered fullscreen. As the proposed spec is written so far, I think Document.fullscreen is meant to convey that: 1. If the document's full-screen element in the document, the full-screen element is rendered at viewport dimensions with browser UI hidden, or 2. if the document's full-screen element is not in the document, the document is rendered at viewport dimensions. The key is the :full-screen psuedo-class, for which the suggested UA style rules enables the full-screen element appear to break out of containing frames and be rendered at the view-port size (assuming the browser window is made viewport dimensions by the UA). The :full-screen pseudo-class is defined to also apply to an iframe, object or embed element whose child browsing context's Document is in the full-screen state. So if a child document in an iframe doesn't have its full-screen element in the document, unless the document reports being in full-screen state the :full-screen pseudo-class won't apply to that document, and that document thus won't be rendered at viewport dimensions. If we specified a Document.currentFullScreenElement attribute, then Document.fullScreen would be equivalent to (Document.currentFullScreenElement != null). Regards, Chris Pearce.
Re: [whatwg] [fullscreen] cancelFullScreen()
It seems to me that being fullscreen is a property of the top-level
browsing context. All that is potentially associated with a document is
the fullscreen element. If you have a document A with two
sub-documents B and C, it does not make much sense to me that if you go
fullscreen from B, C would not report as being fullscreen. I mean
sure, there is no fullscreen element but it is definitely rendered
fullscreen.
As the proposed spec is written so far, I think Document.fullscreen is
meant to convey that:
1. If the document's full-screen element is in the document, the
full-screen element is rendered at viewport dimensions with browser
UI hidden, or
2. if the document's full-screen element is not in the document, the
document is rendered at viewport dimensions.
Does it make any sense to say there is a fullscreen element ? Documents
are fullscreen, elements wrap some content and add structure.
How can 1. be achieved in a predictable non-magic manner ? If you have a
video element with a custom UI, the custom UI, which will be nothing more
than some elements, needs to stretch, and then if you use javascript to
query layout information, that needs to be visible.
So, the only thing that the user agent should do (which they do now
already) is to remove the browser chrome.
The webpage can then with a fragment if css stretch whatever needs
stretching.
# .my-fullscreen-video.container {
position:fixed;z-index:999;left:0;top:0;width:100%;height:100% }
Or do something even more complex. So, the user agent should not do any
kind of implicit resizing of elements.
The key is the :full-screen psuedo-class, for which the suggested UA
style rules enables the full-screen element appear to break out of
containing frames and be rendered at the view-port size (assuming the
browser window is made viewport dimensions by the UA).
The :full-screen pseudo-class is defined to also apply to an iframe,
object or embed element whose child browsing context's Document is
in the full-screen state. So if a child document in an iframe doesn't
have its full-screen element in the document, unless the document
reports being in full-screen state the :full-screen pseudo-class won't
apply to that document, and that document thus won't be rendered at
viewport dimensions.
If we specified a Document.currentFullScreenElement attribute, then
Document.fullScreen would be equivalent to
(Document.currentFullScreenElement != null).
Why the need for a :full-screen selector ? Aren't media queries enough or
even more semantically correct ?
And then why the need for document.fullScreen ? The media query API that
Anne was writing should work too to query if fullscreen is enabled. [1]
# var in_fullscreen = matchMedia((fullscreen:on)).matches
If the use cases can be cleanly represented using just CSS and generic
APIs, then better,
[1] http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface
Lastly, where is the specification ? If there an official working draft ?
[whatwg] [fullscreen] cancelFullScreen()
Is cancelFullScreen() synchronous or should it queue a task? If you invoke cancelFullScreen() on a Document of a parent or child browsing context from the browsing context in whose Document requestFullScreen() was invoked it should presumably still work, no? Presumably also if the Document has been navigated away from. In what scenarios does the for example the UA might require that only a Document that last triggered full-screen can cancel it provision apply? It is really quite confusing in the draft what full screen is associated with. A Document, a top-level browsing context, the user agent? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [fullscreen] cancelFullScreen()
On 12/10/2011 10:35 p.m., Anne van Kesteren wrote: Is cancelFullScreen() synchronous or should it queue a task? Synchronous, so that Document.fullScreen immediately reflects the state change? Why would it need to be asynchronous? If you invoke cancelFullScreen() on a Document of a parent or child browsing context from the browsing context in whose Document requestFullScreen() was invoked it should presumably still work, no? The parent of a Document which is in full-screen will also be in full-screen mode. So if cancelFullScreen() is invoked in the parent Document, it should exit full-screen in the parent. I interpreted the spec to mean if one full-screen document cancels full-screen, all documents in the tree exit full-screen mode. I too have been wondering if we should honour calls to cancelFullScreen() in a non-full-screen child Document of the Document which requested full-screen. Presumably also if the Document has been navigated away from. FWIW we're planing to exit full-screen when a full-screen document is navigated. Probably a good idea to spec this so it's consistently implemented. Chris Pearce.
Re: [whatwg] [fullscreen] cancelFullScreen()
On Thu, 13 Oct 2011 11:26:20 +0900, Chris Pearce cpea...@mozilla.com wrote: On 12/10/2011 10:35 p.m., Anne van Kesteren wrote: Is cancelFullScreen() synchronous or should it queue a task? Synchronous, so that Document.fullScreen immediately reflects the state change? Why would it need to be asynchronous? Is the event dispatched synchronously as well then? I was thinking that maybe you want to trigger an animation here of some kind. Though I suppose that could be done synchronously as well. If you invoke cancelFullScreen() on a Document of a parent or child browsing context from the browsing context in whose Document requestFullScreen() was invoked it should presumably still work, no? The parent of a Document which is in full-screen will also be in full-screen mode. So if cancelFullScreen() is invoked in the parent Document, it should exit full-screen in the parent. I interpreted the spec to mean if one full-screen document cancels full-screen, all documents in the tree exit full-screen mode. I too have been wondering if we should honour calls to cancelFullScreen() in a non-full-screen child Document of the Document which requested full-screen. It seems to me that being fullscreen is a property of the top-level browsing context. All that is potentially associated with a document is the fullscreen element. If you have a document A with two sub-documents B and C, it does not make much sense to me that if you go fullscreen from B, C would not report as being fullscreen. I mean sure, there is no fullscreen element but it is definitely rendered fullscreen. Presumably also if the Document has been navigated away from. FWIW we're planing to exit full-screen when a full-screen document is navigated. Probably a good idea to spec this so it's consistently implemented. Okay. -- Anne van Kesteren http://annevankesteren.nl/
