[whatwg] Feedback on the Mozilla FullScreen API proposal

[Simon Fraser]

This is feedback on the Mozilla FullScreen API proposal here:
<https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI>

> The user agent may transition a Document into or out of the
> fullscreen state at any time, whether or not script has requested
> it. User agents are encouraged to provide standard UI to exit the
> fullscreen state, for example if the user presses the Escape key.

Does this imply that the UA has a "fullscreen" button, when
the user uses this to make the window fullscreen, then the
CSS pseudoclasses described in this document are applied?
I'm not sure that's always desirable; I think it might result
in unexpected behavior for users who use the fullscreen button
as an equivalent to maximizing the window.

I'd suggest that the CSS pseudoclasses are only applied when the
fullscreen JS API has been called by the web content.

>  * void cancelFullScreen()

I think "exit" would be better than "cancel".

> New methods of Document:
>  * void requestFullScreen()
>  * void requestFullScreenWithKeys()

> New methods of Element:
>  * void requestFullScreen()
>  * void requestFullScreenWithKeys()

Do we really need to add these to both Document and Element?
It seems like the Document ones could be removed; if an
author wants to take the Documemnt fullscreen, they simply
call the methods on document.documentElement.

I'm not fan of "WithKeys" in the method names. Out of
context, it's not clear what "keys" means. I think
"keyboardInput" or "keyInput" would be more understandable.
Also, why not just use a parameter:

    void requestFullScreen(bool allowKeyboardInput)
    
or have some constants for behavior:

    const unsigned short ALLOW_KEYBOARD_INPUT = 1;
    void requestFullScreen(unsigned short behavior)
    
This would be extensible, and would allow us to permit other
behaviors later.

Why don't requestFullScreen()/requestFullScreenWithKeys() return
a boolean value indicating whether the UA will allow the request
to proceed? The author has no information about whether fullscreen
is going to happen after making this call, and UAs will certainly
want to deny fullscreen in various situations.

> New content attribute of the <iframe> element:
>  * allowfullscreen
> This is a boolean attribute. When this attribute is not set, UAs
> should ignore fullscreen requests in the iframe or its descendants.

Descendant nodes, or descendant iframes?

> * :full-screen-doc

I don't like the abbreviation of "document" here. Would "page"
be a better term to use than "document" for these?

>  * :full-screen-doc
> While a Document is in the fullscreen state, the 'full-screen-doc'
> pseudoclass applies to the root element of that Document.
> 
>  * :full-screen-doc-with-target
> While a Document is in the fullscreen state and the document's
> current fullscreen element is an element in the document, the
> 'full-screen-doc-with-target' pseudoclass applies to the root
> element of that Document.

Just to be clear, if a document is fullscreen, and the fullscreen
element is not the document element, then the document element
will get both these pseudoclasses? What happens when the
fullscreen element is the the document element?

I'd like to see the proposal fleshed out to address the following
scenarios:

* the document is fullscreen, and navigation happens
* the document is fullscreen, and the content calls requestFullScreen()
  again (possibly with a different element, possibly inside an iframe).
* the document is fullscreen, and the fullscreen element is removed
  from the DOM
* the document is fullscreen, and the fullscreen element has 
  display:none set on it.
* consideration of whether the fullscreen API can be called at
  any time (risk of "drive-by-fullscreening").
* affect, if any, on calls to focus() on elements which are not children
  of the fullscreen element.
  
Thanks
Simon