[whatwg] api for fullscreen()

[Robert O'Callahan]

On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser <smfr at me.com> wrote:

> We have been discussing a more general fullscreen API that lets you take
> the page fullscreen (perhaps with the ability to focus on a single element),
> as Maciej mentions. We have not decided on a final form for this API, nor
> have we resolved whether it's possible to do some nice transition between
> the two modes. We have talked at some length about the security issues.
>
> Input on what people would like from this API is welcome, as are ideas on
> how the transitions should work.
>

1) Should be convenient for authors to make any element in a page display
fullscreen
2) Should support in-page activation UI for discoverability
3) 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.
4) Should accommodate potential UA security concerns, e.g. by allowing the
transition to fullscreen mode to happen asynchronously after the user has
confirmed permission

*** WARNING: totally half-baked proposal ahead! ***

New API for all elements:
void enterFullscreen(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.

supportsFullscreen returns false if it's impossible for this element to ever
be shown fullscreen. It does not reveal whether permission will be granted.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100129/f4d63f4a/attachment-0002.htm>