[whatwg] Feedback on the Mozilla FullScreen API proposal

On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser <smfr at me.com> wrote:

> 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?
>

Yes, that's the idea. We want to be able to integrate fullscreen UI with
scripted fullscreen.


> 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.
>

Well, that's up to the UA; you can have a fullscreen mode that doesn't put
the document into the fullscreen state, if you want.

Note that the API lets authors distinguish "fullscreen with a specific
targeted element" vs "fullscreen with no targeted element", and a basic
fullscreen UI would only enter the latter mode. So I don't think you'll get
unexpected behavior in practice if they're integrated.

Personally I think they should be integrated. For example, if you have a
canvas game that occupies most of the window except for some instruction
text, and the game has a fullscreen command that makes the canvas fill the
window and resizes the canvas buffer to the window size, I think it would be
nice for the UA's fullscreen UI to trigger the same behavior. Or maybe you
have a slide viewer and you want the UA's fullscreen UI to trigger
fullscreen presentation mode. This API makes that possible.

>  * void cancelFullScreen()
>
> I think "exit" would be better than "cancel".
>

The only problem with "exit" is that you might call it when you're not
actually in fullscreen state, since requests are asynchronous. I think of it
more as cancelling the request than actually forcing a change.

> 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.
>

Yes, we can do that. This means getting rid of the concept of not having a
fullscreen element, and instead special-casing the case where the fullscreen
element is the root element in a few places. But I think that's probably a
win. Thanks.

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.
>

OK.


> Also, why not just use a parameter:
>
>    void requestFullScreen(bool allowKeyboardInput)
>

boolean parameters are bad style IMHO. It's hard to tell at the call site
what they mean.

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.
>

Sure.

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.
>

The UA may not be able to make a decision synchronously. Permitting
asynchronous decisions about whether to permit fullscreen was a key goal
here. For example that gives UAs the option of presenting passive
confirmation UI.

> 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?
>

Descendant frames. I'll clarify that.

> * :full-screen-doc
>
> I don't like the abbreviation of "document" here. Would "page"
> be a better term to use than "document" for these?
>

We can just make it ':full-screen-document'.

>  * :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?


Correct.

What happens when the
> fullscreen element is the the document element?
>

As written, it would get all three pseudoclasses. But I think we can get rid
of full-screen-doc-with-target completely.

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.
>

Done. In most of those cases, nothing special happens. That is intentional;
for example, I think trying to special-case handling of display:none or
focus would quickly add a lot of complexity.

Thanks for the feedback!

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100806/8b6d3c0f/attachment-0001.htm>

Received on Thursday, 5 August 2010 17:56:19 UTC