On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser <span dir="ltr"><<a href="mailto:smfr@me.com" target="_blank">smfr@me.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div style="word-wrap: break-word;">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.<div>

<br></div><div>Input on what people would like from this API is welcome, as are ideas on how the transitions should work.</div></div></blockquote></div><br>1) Should be convenient for authors to make any element in a page display fullscreen<br>

2) Should support in-page activation UI for discoverability<br>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.<br>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<br><br>*** WARNING: totally half-baked proposal ahead! ***<br>
<br>New API for all elements:<br>void enterFullscreen(optional boolean enableKeys);<br>void exitFullscreen();<br>boolean attribute supportsFullscreen;<br>boolean attribute displayingFullscreen;<br>"beginfullscreen" and "endfullscreen" events<br>
<br>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.<br>
<br>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).<br>
<br>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.<br>
<br>In principle a UA could support multiple elements in fullscreen mode at 
the same time (e.g., if the user has multiple screens).<br><br>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.<br>
<br>supportsFullscreen returns false if it's impossible for this element to ever be shown fullscreen. It does not reveal whether permission will be granted.<br><br>Rob<br>-- <br>"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]<br>