W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2011

[whatwg] Fullscreen

From: Chris Pearce <cpearce@mozilla.com>
Date: Mon, 17 Oct 2011 12:22:22 +1300
Message-ID: <4E9B672E.9060101@mozilla.com>
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.
Received on Sunday, 16 October 2011 16:22:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:37 UTC