- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Fri, 29 Jan 2010 15:42:51 +1300
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.htm>
Received on Thursday, 28 January 2010 18:42:51 UTC