Monday, February 1st, 2010
>What can you do if you want to enable a fullscreen experience on the Web? You can’t. Or, use Flash. Some claim that you shouldn’t offer this ability as it is a security liability. Someone can put a fullscreen view that tricks the user into giving it information.
However, as much as I think user security is important, it doesn’t seem like we can punt and not do anything because of this. A user agent can do a lot of things to help out.
Some (majority?) of the use cases revolve around full screen video. Eric Carlson has a WebKit checkin that enables that one case. You can
webkitEnterFullScreen() on a HTML5 video element and be on your way.
You can see this in action on the SublimeVideo HTML5 player. Play the video in WebKit nightly and alt-click the “full size” arrows.
Video is great, but what about general purpose? What if you could fullscreen any element? Robert O’Callahan threw up a strawman:
- Should be convenient for authors to make any element in a page display fullscreen
- Should support in-page activation UI for discoverability
- Should support changing the layout of the element when you enter/exit fullscreen mode. For example, authors probably want some controls to be fixed size while other content fills the screen.
- Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission
- void enterFullscreen(optional DOMElement element, optional Screen, optional boolean enableKeys);
- void exitFullscreen();
- boolean attribute supportsFullscreen;
- boolean attribute displayingFullscreen;
- //"beginfullscreen" and "endfullscreen" events
While an element is fullscreen, the UA imposes CSS style “position:fixed; left:0; top:0; right:0; bottom:0″ on the element and aligns the viewport of its DOM window with the screen. Only the element and its children are rendered, as a single CSS stacking context.
enterFullscreen always returns immediately. If fullscreen mode is currently supported and permitted, enterFullscreen dispatches a task that a) imposes the fullscreen style, b) fires the beginfullscreen event on the element and c) actually initiates fullscreen display of the element. The UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never).
The enableKeys parameter to enterFullscreen is a hint to the UA that the application would like to be able to receive arbitrary keyboard input. Otherwise the UA is likely to disable alphanumeric keyboard input. If enableKeys is specified, the UA might require more severe confirmation UI.
In principle a UA could support multiple elements in fullscreen mode at the same time (e.g., if the user has multiple screens).
enterFullscreen would throw an exception if fullscreen was definitely not going to happen for this element due to not being supported or currently permitted, or if all screens are already occupied.
Much talking of exact API issues and more security…. but hopefully inertia does it job and we get something.
Would you like a fullscreen API?
Posted by Dion Almaer at 6:26 am