[whatwg] Fullscreen

Chris Pearce cpearce at mozilla.com
Sun Oct 16 16:22:22 PDT 2011

On 17/10/2011 5:31 a.m., João Eiras wrote:
> a)
> The fullscreen media query is missing (I seriously suggest supporting it)
> # @media all and (full-screen) { /* ... */ }
> Does it make sense to have on/off as in the Mozilla proposal ? e.g. 
> "and (full-screen:on/ff)" ?

We removed this from our proposal, since the view-mode media query has a 
fullscreen mode. However the view-mode media query does not distinguish 
between browser fullscreen mode (pressing F11 in Firefox and the same in 
Opera) and DOM full-screen mode, where a particular element is 
fullscreen. You need Document.fullscreen for that. Perhaps this is 
indeed an argument for including a separate media query for the 
fullscreen API's fullscreen mode.

> b)
> I think that :fullscreen should not apply if there is no fullscreen 
> element.

When is there no fullscreen element? When the fullscreen element isn't 
in the document? Without the :fullscreen rule, containing frames won't 
have the styles applied that enables iframe contents to appear fullscreen.

> c)
> There should be a security note for 
> request/cancel/enter/exitFullscreen that the user agent might choose 
> to dishonor the calls to these methods, like if fullscreeen is not 
> supported, or the browsing context is child of another one that does 
> not allow fullscreen, or the call to these methods is not from a user 
> initiated action.

This is implied by aborting when any ancestor browsing context's 
document doesn't have the fullscreen enabled flag set.

> I would remark that user agents should ignore calls to those methods 
> if not coming from a user initiated action (kind like the way pop ups 
> are handled). So, the click to go fullscreen button use case works, 
> but a webpage going fullscren during load and then spoof the browser 
> UI would not.

I agree, in fact we're doing this already in our implementation. Do we 
need to add this to the spec as a recommendation?

> d)
> Perhaps a non normative note just to explain that the flags do would 
> be nice for authors. 

I agree, this would make the spec more approachable.

> e)
> Given their use cases, the flag fullscreenEnabled would be better 
> called fullscreenAllowed, and the fullscreen flag would be better 
> called fullscreenEnabled.

fullscreenEnabled is better, as fullscreenAllowed implies that the 
request is going to be granted, whereas fullscreenEnabled doesn't imply 
that. For example, requests for fullscreen would still be denied if not 
coming from a user-generated event handler even if 
document.fullscreenEnabled returned true.

Chris Pearce.

More information about the whatwg mailing list