On Jan 30, 2010, at 1:24 PM, Anne van Kesteren wrote:
> On Sat, 30 Jan 2010 22:12:47 +0100, Simon Fraser <s...@me.com> wrote:
>> On Jan 29, 2010, at 9:54 PM, Robert O'Callahan wrote:
>>> So how about a Window API with an optional element component:
>>> void enterFullscreen(optional DOMElement element, optional boolean
>>> enableKeys);
>>> void exitFullscreen();
>>> boolean attribute supportsFullscreen;
>>> boolean attribute displayingFullscreen;
>>> "beginfullscreen" and "endfullscreen" events
>>>
>>> Where "beginfullscreen" and "endfullscreen" are targeted at the element if
>>> one was provided, or else at the window, and bubble. While a window is
>>> fullscreen, the root element and the designated fullscreen element, if any,
>>> are given a pseudoclass "fullscreen". Then you can have some default rules
>>> in the UA style sheet:
>>> *:root:fullscreen { overflow:hidden; }
>>> *:not(:root):fullscreen { position:fixed; left:0; top:0; bottom:0; right:0;
>>> }
>>
>> I'll go for that.
>>
>> Another good argument to have this API on the window object is that
>> fullscreen is effectively a state on the window. It would not make any sense
>> to go fullscreen on one element, and then fullscreen on another element.
>>
>> Should enterFullscreen() throw an exception if already fullscreen?
>
> To stop polluting the Window object, might it make sense to put the new
> members (other than event handler attributes) on window.screen?
This would require that the current window object is passed implicitly to the
method, so the UA knows which window to take fullscreen, right?
This talk of going into fullscreen on different screens at the same time makes
me think that the screen should be an optional argument:
void enterFullscreen(optional DOMElement element, optional Screen, optional
boolean enableKeys);
with the default screen being either the main screen, or window.screen.
Simon
