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

[whatwg] api for fullscreen()

From: Brian Campbell <lambda@continuation.org>
Date: Mon, 1 Feb 2010 19:32:10 -0500
Message-ID: <7B515388-6524-4F71-8F18-7C088A649B1A@continuation.org>

On Feb 1, 2010, at 5:38 PM, Robert O'Callahan wrote:

> On Tue, Feb 2, 2010 at 10:41 AM, Brian Campbell <lambda at continuation.org> wrote:
> I'm a bit concerned about when the fullscreen events and styles apply, though. If the page can tell whether or not the user has actually allowed it to enter fullscreen mode, it can refuse to display content until the user gives it permission to enter fullscreen mode. Or even if it's not refusing to display content, it may simply not scale the content up to the full window if the user neglects to give permission for full screen.
> 
> We could simply modify the proposal to apply the fullscreen pseudoclass (but not fullscreen the window) if permission is denied.

The user may never notice the notification and explicitly deny permission; the whole point of asynchronous notifications is that they are less obtrusive and not modal, but that means that users can ignore or fail to notice them and keep going without ever dismissing them.

I think it would be best to immediately go as full screen as possible (so, full window if permission hasn't yet been given), and then resize to full screen if permission is granted. This will avoid content authors having to duplicate that same functionality themselves for their users that don't ever give or deny permission.

Resizing when in full screen mode will need to be implemented anyhow, to support devices like the iPhone or iPad which can change orientation and will need to reshape the screen.

> However, in general I don't think we can prevent Web content from detecting that it is not fullscreen. For example it could check whether the window size is one of a set of common screen sizes.

No, you can't stop someone who is truly dedicated from guessing based on the exact size. My concern is more with authors who feel that their content is best displayed in full screen, and so may simply refuse to play it until they've gotten the fullscreen event or have the fullscreen pseudoclass. That would be pretty easy to implement, if you have that functionality available to you. I know my previous director would have requested it; he is very particular about content being displayed in full screen, and while I would argue that we shouldn't lock people out who don't want to be in full screen mode, I may have been overruled if such functionality were available and so easy to use.

Here are three possible scenarios, for the user clicking the "fullscreen" button on some content and then denying permission to allow full screen access:

1) The original proposal: 
  * User clicks "full screen" button. 
  * Notification pops up, no events are sent or classes applied. 
  * User clicks "deny", no events are sent or classes applied. 
  * The user's full screen request has been ignored, and now the page author needs to do something special to resize to the full window if desired.
2) Your suggestion above, to apply the pseudoclass if permssion is denied: 
  * User clicks "full screen" button. 
  * Notification pops up, no events sent or classes applied. 
  * User clicks "deny", and fullscreen class is applied. 
  * You didn't mention whether you intend for the event to also be sent, and content automatically resized to fit the viewport; if that doesn't happen, then the page author needs to add special handling for expanding the content to the full window, or something of the sort. 
  * At this point, you have an odd effect, in which denying permission for full screen causes the content to scale to the full window.
3) My suggestion: 
  * The user clicks "full screen". 
  * Notification pops up, content scales up to fill the window, pseudoclass is applied, event is sent. 
  * The user clicks "deny", which simply dismisses the notification. 
  * The content is now accessible, in pseudo fullscreen mode, giving the user access to the controls and content for that mode.

This may not be the most common use case, of the user clicking the "fullscreen" button and then denying permission, but I think that my proposal gives a fairly sensible behavior for that use case, encouraging a user friendly experience without requiring the author to do too much extra work, and without encouraging content to be unavailable outside of full screen mode.

Of course, much of this discussion is of details that could be left up to the UA. As far as the spec is concerned, the main points to include would be that the fullscreen events, class, and resizing may occur even when the content is not actually being displayed on the full screen, and that resizing may occur after entering fullscreen mode.

-- Brian
Received on Monday, 1 February 2010 16:32:10 UTC

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