Monday, February 1st, 2010

fullscreen API coming to browsers near you?

Category: Browsers

>What can you do if you want to enable a fullscreen experience on the Web? You can’t. Or, use Flash. Some claim that you shouldn’t offer this ability as it is a security liability. Someone can put a fullscreen view that tricks the user into giving it information.

However, as much as I think user security is important, it doesn’t seem like we can punt and not do anything because of this. A user agent can do a lot of things to help out.

Some (majority?) of the use cases revolve around full screen video. Eric Carlson has a WebKit checkin that enables that one case. You can webkitEnterFullScreen() on a HTML5 video element and be on your way.

You can see this in action on the SublimeVideo HTML5 player. Play the video in WebKit nightly and alt-click the “full size” arrows.

html5sublimevideo

Video is great, but what about general purpose? What if you could fullscreen any element? Robert O’Callahan threw up a strawman:

  1. Should be convenient for authors to make any element in a page display fullscreen
  2. Should support in-page activation UI for discoverability
  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

New API for all elements:

javascript
< view plain text >
  1. void enterFullscreen(optional DOMElement element, optional Screen, optional boolean enableKeys);
  2. void exitFullscreen();
  3. boolean attribute supportsFullscreen;
  4. boolean attribute displayingFullscreen;
  5. //"beginfullscreen" and "endfullscreen" events

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.

enterFullscreen always returns immediately. If fullscreen mode is currently supported and permitted, enterFullscreen dispatches a task that a) imposes the fullscreen style, b) fires the beginfullscreen event on the element and c) actually initiates fullscreen display of the element. The UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never).

The enableKeys parameter to enterFullscreen is a hint to the UA that the application would like to be able to receive arbitrary keyboard input. Otherwise the UA is likely to disable alphanumeric keyboard input. If enableKeys is specified, the UA might require more severe confirmation UI.

In principle a UA could support multiple elements in fullscreen mode at the same time (e.g., if the user has multiple screens).

enterFullscreen would throw an exception if fullscreen was definitely not going to happen for this element due to not being supported or currently permitted, or if all screens are already occupied.

Much talking of exact API issues and more security…. but hopefully inertia does it job and we get something.

Would you like a fullscreen API?

Related Content:

Posted by Dion Almaer at 6:26 am
18 Comments

+++--
3.2 rating from 30 votes

18 Comments »

Comments feed TrackBack URI

Would be a nice feature if used responsibly, but it seems there is a lot of potential for misuse. HTML 5 could become a world of full-screen pop-up ads.

Comment by WillPeavy — February 1, 2010

I would love to have the option giving Fullscreen-Mode to a specific element, keep going :)

Comment by gossi — February 1, 2010

Just use the same model as Flash where the fullScreen event can only be activated via a user click event… NEVER allow full screen adhoc from the code.

Comment by RoryH — February 1, 2010

I think that the browser should ask permission to the user, to use full screen.

EX:

Do you want to have this site use your full screen.

(Yes) (No) (I don’t know)

And you get the full screen you get something like in flash that says you only need to click on esc on your keyboard to get ride of the full screen.

We could also see in the corner of the screen a small icon that shows that your full screen. And it would be impossible to remove or to hide.

Does are my solutions to the security problem.

Comment by jnbdz — February 1, 2010

An important aspect of full-screen mode in flash is that users can’t enter text while they are in full-screen mode, so evil sites won’t trick them into entering their password. If you take away the ability of entering text (and really, you should), aside from video there’s simple not much use to full-screen mode.

Comment by Joeri — February 1, 2010

hi there,

would love a FULL SCREEN API. cool.

BR,
~A

Comment by anjanb — February 1, 2010

I think a bottom left corner icon would be a good visual cue, also I think tasteful alternate CSS Cursors applied with User Style Sheet priority would be a good idea. Then we could have text input enabled with a custom cursor that would let End Users see they were interacting with a full screen web page generated dialog. The custom cursors would need to be recognizable across platforms (in case the full screen application was deployed to drive information kiosks running heterogeneous configurations) and could consist of the standard cursors combined with an asterisk or some other platform independent annotation mark.

Comment by IEUCActual — February 1, 2010

Well fullscreen video capability is probably a must if html5 video is to compete effectively with flash, but beyond that Im not so sure – ok probably webGL also needs a fullscreen capability.

Comment by SteveElbows — February 1, 2010

It would be funny if something like this forced Safari to support full screen browsing.

Comment by JonathanLeech — February 1, 2010

I’ll second the “if HTML5 video is going to compete with Flash” sentiment, though I’d extend fullscreen mode’s usefulness to Canvas as well. Fullscreen Flash is most useful for games and videos, i.e., Canvas and .

Having a confirmation dialog (“Do you want to allow this site to use your full screen?”) reeks of Windows’ UAC. Any security restrictions need to be transparent to the user.

Comment by kadams54 — February 1, 2010

I don’t know about ‘make any element in a page display fullscreen’, but in Opera, if I go full screen, the page actually takes up the entire screen; no tabs, no menus, nothing.

Comment by abhijitn — February 1, 2010

We keep hitting this problem in browsers. We need to stop coming down on the side of always disallowing behaviors if we want the web platform to be used for real applications.

A simple “This website is requesting to use the full screen. Would you like to allow this?” [Yes/No/Always for youtube.com] is the correct solution for this and any other case where there is potential for abuse of a new capability.

Comment by cyrusomar — February 1, 2010

A fullscreen API is a must if we’re to replace Flash video players with native, browser video players.

As long as we can only go into fullscreen mode based on some user input ( a click or keystroke ) we should be fine.

Comment by hdragomir — February 1, 2010

Is hitting F11 really that difficult?

Comment by grayrest — February 2, 2010

Hitting F11 doesn’t fullscreen the video player. It fullscreens the whole page, which is a different thing. Try F11 on youtube (even the HTML5 version) to appreciate the difference.

Comment by pmontrasio — February 2, 2010

Why not follow what the spec says (read octavem’s post): let the user-agent (the browser) provide the fullscreen capability. First the user clicks a button on the video players controls that sets the video element’s to the size of the viewport, and the viewports overflow property is set to hidden. Then the user presses F11, to enter fullscreen browsing mode. The second step could be done first, it doesn’t really matter. If you’re on a site like YouTube, you could remain in fullscreen browsing mode while navigating to other videos.

But this would require the user to not only click the fullscreen button on the video element’s player controls, but then would have to press F11. At least there wouldn’t be a need for the user to be prompted to go to fullscreen mode. However one could argue which is worse, a prompt or a two-step process?

I think that the Web platform should be unobtrusive to the user to begin with (ala Google Chrome). However there will be times when an application, such as a video game, would require the users entire screen. So maybe a fullscreen standard should be taken into consideration.

Comment by Figaro — February 2, 2010

Fullscreen API would be wonderful. Personally I’ve been waiting for a kind of kiosk mode standard in browsers but it seems it’s not going to happen. Fullscreen API would is a necessity, even if annoyance avoidance is tough.

Comment by AMIGrAve — February 17, 2010

The solution, security wise, is quite simple. The browser should simple filter all keyboard input except for escape and space. Additionally a faded popover should inform the user of entering fullscreen, the same as flash.

There would be no ability to type in a password.

Comment by convivialdingo — February 24, 2010

Leave a comment

You must be logged in to post a comment.