On Sat, 15 Oct 2011 05:27:21 +0100, Anne van Kesteren <ann...@opera.com>
wrote:
I wrote up a draft:
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
(...)
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)" ?
b)
I think that :fullscreen should not apply if there is no fullscreen
element. It would make the CSS snippet simpler, and the media query would
still allow fullscreen styles to be applied. It also allows the user agent
from optimize a bit to skip that fullscreen CSS snippet if there is no
fullscreen element bound. And the CSS snippet as mentioned applies only to
HTML, so another use case to have a media query.
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. 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. It would also make the use
case for requestFullScreenWithKeys API less interesting.
d)
Perhaps a non normative note just to explain that the flags do would be
nice for authors. fullscreen tells if the document is being rendered
fullscreen (a shortcut to check if the media query applies), and
fullscreenEnabled tells if the document is allowed to go fullscreen using
the enter/requestFullscreen API.
e)
Given their use cases, the flag fullscreenEnabled would be better called
fullscreenAllowed, and the fullscreen flag would be better called
fullscreenEnabled.
So far, nice work.
