W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] api for fullscreen()

From: Simon Pieters <simonp@opera.com>
Date: Thu, 17 Dec 2009 10:52:10 +0100
Message-ID: <op.u42to8huidj3kv@zcorpandell.linkoping.osa>
On Thu, 17 Dec 2009 10:30:26 +0100, Maciej Stachowiak <mjs at apple.com>  

> Some of us at Apple have discussed fullscreen APIs, and we think a user  
> gesture requirement plus clear indication of what has happened is likely  
> sufficient.
> As to the API itself: we tentatively think a good API would be to make a  
> specific *element* go full screen, rather than the whole Web page. Some  
> use cases for fullscreen will indeed want to transition the whole page,  
> for example, let's say a Web-based editor wants to provide a  
> distraction-free fullscreen mode like WriteRoom. However, it seems like  
> many common use cases will benefit most from taking only part of the  
> page full-screen, for example video or games, where it's common for the  
> original content to only be a small box in the page.
> Now, content could just manually hide the parts of the page in response  
> to an event. Or you could provide a special media type or pseudo-class  
> to use CSS to hide the unwanted content.

In Opera, @media projection targets full-screen mode. It's possible though  
that a page would want different styles when the whole page is in full  
screen and when an element is in full screen.

> But taking an element rather than a page full-screen has two benefits:
> 1) It handles some very common use cases (including likely one of the  
> *most* common, video) in a way that's much simpler for the content  
> author.
> 2) The browser will have the option to animate the transition to  
> fullscreen starting from the target element, in a clean way. If content  
> has to make layout changes by hand to limit itself to the specific  
> fullscreen target, then it's extremely difficult, perhaps impossible,  
> for the browser to do a single smooth animated transition without any  
> unwanted flickering or layout thrash.
> We don't have a specific API proposal to make right now, but I'll try to  
> get the people working on this to put forward a concrete proposal soon.
> Regards,
> Maciej

Simon Pieters
Opera Software
Received on Thursday, 17 December 2009 01:52:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:54 UTC