[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 <cpearce at 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.

Received on Thursday, 13 October 2011 03:21:59 UTC