On Jan 28, 2010, at 6:42 PM, Robert O'Callahan wrote: > On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser <s...@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
I agree with Boris that we should leave this up to the page author. > 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 Agreed. > > New API for all elements: > void enterFullscreen(optional boolean enableKeys); > void exitFullscreen(); > boolean attribute supportsFullscreen; > boolean attribute displayingFullscreen; > "beginfullscreen" and "endfullscreen" events Those seem reasonable for a proposal where a single element is taken fullscreen. > 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. So this makes it a very element-focused API (as does the enterFullscreen() method on Element that you propose above). Another approach would be to leave it entirely up to the page author to style their page differently when in fullscreen, and not have the API force them to focus on one element. Then the API would probably be on the Window object, and the UA would simply transition the view to a fullscreen presentation. There could be a pseudo-class to the body, or a way to use media queries to allow the author can apply different styles for fullscreen. In this scenario the author is not forced to nest all their fullscreen content under one element, and can continue to show the rest of the page content (maybe dimmed out by a semi-transparent overlay div) in the background. The disadvantage of this approach is that it makes it much harder for the UA to do any kind of automatic transitions between the two presentations (though it's not clear to me that nice automatic transitions will be possible with the element-based API either). Simon
