[whatwg] api for fullscreen()

[Darin Fisher]

On Thu, Jan 28, 2010 at 6:42 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> 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.
>

Note:  The "if all screens are already occupied" implies acquiring some
global lock before returning from this method.  That's not so great for a
multi-threaded UA.  I'd prefer if we just defined an asynchronous error
event that could be used to report rejections.

-Darin


>
> 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/20100130/c1fd3efb/attachment.htm>