- From: Anne van Kesteren <annevk@opera.com>
- Date: Sat, 30 Jan 2010 22:24:34 +0100
On Sat, 30 Jan 2010 22:12:47 +0100, Simon Fraser <smfr at 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? -- Anne van Kesteren http://annevankesteren.nl/
Received on Saturday, 30 January 2010 13:24:34 UTC