W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] api for fullscreen()

From: Kit Grose <kit@iqmultimedia.com.au>
Date: Thu, 4 Feb 2010 10:03:49 +1100
Message-ID: <A21366E7-BCB2-4681-8721-EA4D6954412C@iqmultimedia.com.au>
> Another scenario applies to most video player sites. Almost all video player sites using Flash have a full screen button. Many of them do not have a full window button, however. If a user wishes to view content scaled up to fill the window, without the distractions of navigational links, comments, descriptions, and so on, they don't usually have a way to do this. If it were possible to use the full-screen button, but deny permission to actually go full screen, and have that simply display the content in the full window exactly as if it were full screen, it would give the users more control over how they view the content.

I don't agree that this behaviour is not expected. Many kinds of full-screen applications (web/Flash or otherwise) require that they are run at the highest window level for the reasons you mentioned (distractions, time-sensitive response; a web-based IDE like Bespin could, with a full-screen mode, become a WriteRoom equivalent for the web). Imagine an educational website where the page gives the user a passage of text then asks to go full-screen to perform an examination on that material; having the ability to have other windows open concurrently defeats the purpose of the application.

I feel that the user shouldn't have the ability to enter into some sort of "pseudo-fullscreen". If the content needs to be displayed full-screen, a user denying the application access to that full-screen capability is a user who does not wish to engage with that application as designed. When it comes to the user wishing "to view content scaled up to fill the window", that's functionality we can already provide and should continue to be the onus of the site's developer if the content is suitable for that kind of consumption (YouTube already has a similar mode, for example).

The advantage to removing that sort of ambiguity is that the page can be clever about how or when it offers fullscreen modes. If, inspecting the window.screen object, the developer determines that the user's screen is not sufficiently large to display his or her game in fullscreen (e.g. on a mobile device), he or she can choose to not show a "fullscreen" button, ensuring that all UI elements of the game are accommodated. If the user's screen is large, but they choose to reject the application's wishes to go fullscreen, the game may not fit (in fullscreen mode) in the browser window.

> I think that this behavior is fairly user hostile, however. There are some times when a user really doesn't want his entire screen filled, for a good reason. If there is content that won't start until the fullscreen event has fired, or fullscreen pseudo-class has been applied, then that user has no choice but to skip that content or allow it to enter fullscreen mode.

If the user does not wish to view the content in full-screen and the developer feels that content can only be reasonably viewed full-screen, I feel the user has opted not to view that content at all. I don't mind at all that the user has no choice but to skip that content; it's similar behaviour to a user quitting a desktop application that insists on running full-screen.

?Kit
Received on Wednesday, 3 February 2010 15:03:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:20 UTC