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.

그러나, 내가 사용자 보안을 중요하다고 생각하는 만큼, 우리가 punt하기 좋아하지 않는것처럼, 이것의 이유는 아무것도 아니다. 한 유저는 돕기위해 많은것을 있다.

Some (majority?) of the use cases revolve around full screen video. Eric Carlson has a WebKit checkin that enables that one case. You canwebkitEnterFullScreen() 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.

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:

PLAIN TEXT

JAVASCRIPT:

1.  
2. void enterFullscreen(optional DOMElement element, optional Screen, optional boolean enableKeys);
3. void exitFullscreen();
4. boolean attribute supportsFullscreen;
5. boolean attribute displayingFullscreen;
6. //"beginfullscreen" and "endfullscreen" events
7.  

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?