[whatwg] Feedback on the Mozilla FullScreen API proposal

[Simon Fraser]

On Aug 5, 2010, at 5:56 PM, Robert O'Callahan wrote:

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

OK, I think it's good to leave this up to the UA.
> 
> >  * 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.

That explains the method name, but I think the most common usage will be to exit fullscreen, rather than to cancel a recent request to enter fullscreen.
> 
> > 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.

Cool.

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

Yes, I like the 'behavior' version.

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

Right. However, I think we need a "fullscreenDenied" event in that case, so the author is informed that their request failed for whatever reason. The most common cause of failure may be that the UA doesn't allow it (e.g. WebKit may make this opt-in for embedding applications, so calling this API in your RSS reader would result in a denied request).

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

Thanks

> 
> > * :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'.

Sounds good.

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

Good.

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

I think the spec needs to at least say what happens here. Does the second call change the fullscreen element to the new element, or is it simply ignored?

> * the document is fullscreen, and the fullscreen element is removed
>  from the DOM

In this case I think you'd either exit fullscreen, or update the pseudostyles to make the document element the new fullscreen element.

> * the document is fullscreen, and the fullscreen element has
>  display:none set on it.

I guess the window just goes blank in this case?

> * consideration of whether the fullscreen API can be called at
>  any time (risk of "drive-by-fullscreening").

We've talked before about limiting the API so fullscreen can only be entered in response to a user event, and I still think that's sensible.

> * affect, if any, on calls to focus() on elements which are not children
>  of the fullscreen element.

Agreed that this could get complex.

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

Are you saying that the spec should not prescribe these behaviors? I think  the UA should be permitted to exit fullscreen in certain scenarios if it deems that necessary for security reasons, as we've discussed before:
<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024897.html>

Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100805/69541f35/attachment-0002.htm>