Kudos to Mozilla (and Robert?). This is awesome. It does appear that you plan
to allow fullscreen without the use of a user-trigggered event such as a
button-click like Flash does. Not only would I like to launch my app in
fullscreen to play a game, I may want to allow my advertisers to launch
fullscreen videos for a premium fee. I think this is a good thing. It's
important to keep restriction versatile so that both the user and developer are
in control. As opposed to too much security completely killing the feature and
force developers to continue to rely upon Flash.
First a small thing. The format of the CSS style:
:full-screen
:full-screen-root-with-target
I don't see why "fullscreen" should be hyphenated. Even the title of the page
uses it as one word.
I don't understand the use of requestFullScreenWithKeys(). Why would I ever use
a more restrictive method? How about just fullscreen() - and it toggles? And
security is handled through element attributes?
I assume the entire reason for security is for third party apps (video) and
advertisements (have I missed an actor?). It seems to me that I would want to
prevent a third party from calling fullscreen. The spec makes it look like its
up to the developer on whether to use the security or not. Did I read it wrong?
The spec focuses a lot on iframes. It's fine to restrict functionality in an
iframe, but a majority of third party apps and advertisements don't happen in
an iframe, they are written to the page, often with document.write – and they
often write their own iframe. The iframe restriction will work for scenarios
such as an HTML5 Video embed, but not for ads.
Here are some suggested constants. The actual spelling or exact usage is not
relevant, I'm addressing functionality (I agree with Anne on constants in JS).
I'm looking at these suggestions mostly from the POV of a web developer, not a
user nor user agent.
The first, simple use case I'm looking to solve is to block your ads from using
fullscreen. I don't see a way to do that in the spec. I recommend the above
options are properties of the document.body:
<body allowFullscreen="blocked">
Note however, that I recommend that allowFullscreen="block" be the default, so
ads can't start launching fullscreen in existing, unmaintained pages.
The second simple scenario is to use fullscreen but you don't need to worry
about ads:
<body allowFullscreen="allow">
The third scenario gets more tricky, and is why I am suggesting using the
properties as node attributes. Think about the NY Times wanting to allow
fullscreen to read the article but block ads (or certain ads) from fullscreen:
<body allowFullscreen="blocked">
<article allowFullscreen="allow">
<aside allowFullscreen="blocked">
The suggestion is that fullscreen permissions are on the element level and are
inherited. Further, they should be only writable in HTML markup, and read-only
in JavaScript so permissions cannot be dynamically changed.
A potential problem is a rouge third party script scanning the page to find the
article element allows fullscreen; and it writes content to it and launches it.
The solution could be that allowFullscreen is NOT readable by JavaScript – it
can only discover permissions by the attempt to go fullscreen.
A modification to this would be a write-once apiKey that is private:
<head>
<scrpt>
document.setFullscreenApiKey("mysecret"); // set only once, subsequent
calls ignored, cannot be read
onClick = function(){
requestFullScreen("mysecret");
}
</scrpt>
<body allowFullscreen="password">
I think this idea is clever, but I may be over thinking it.
allowFullscreen="userIntiated,mouseOnly" is probably all that is needed in this
case (and perhaps most cases).
Of course, nothing is 100% secure, and since this is the list that said DRM is
impossible, I'm really advocating that we don't try for 100% safety and cripple
the feature.
Mike Wilcox
http://clubajax.org
m...@mikewilcox.net
On Aug 5, 2010, at 5:17 PM, Simon Fraser wrote:
> This is feedback on the Mozilla FullScreen API proposal here:
> <https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI>
