Summary

  • W3C's 3 July 2012 Fullscreen Working Draft let an element request fullscreen and a document exit it, while placing fullscreen content in a top layer and preserving a user-directed way out.
  • W3C discontinued that document in 2014 and directed implementers to WHATWG. The current living standard requires a qualifying user action in ordinary cases, controls embedded content through permissions policy, and calls for a browser exit that always works.

Imagine a film festival run by web pages. One exhibitor brings a video and asks to darken the room. Another brings a game and asks for the whole wall. A third arrives with a slide deck and insists the browser's address bar is distracting the audience. Fair enough. Then the venue manager asks where the exits are. Suddenly the projector specification has become a governance document.

The 3 July 2012 W3C Working Draft described a small, powerful interface. Call requestFullscreen() on an element to display it fullscreen. Read fullscreenElement to learn what currently holds the screen. Call exitFullscreen() on the document to stop. Those methods returned void in the draft. It was a first public Working Draft, a design being discussed, and its dates should be read as publication history rather than a claim about which browser reached audiences first.

The draft also described what happens to the scenery. A fullscreen element joined a document's fullscreen stack and the browsing context's top layer, the part drawn nearest the viewer. That matters because a website can already paint a very large rectangle with CSS. Fullscreen changes more than width and height: it brings the browser's viewport, stacking and user interface into the bargain. A div with theatrical confidence cannot simply appoint itself master of the monitor.

The request had conditions. The 2012 algorithm could reject an element outside a document, a context without fullscreen capability, certain conflicting nested states, or a request disallowed under the draft's popup-related condition. It also acknowledged a previously established user preference, security risk or platform limitation. The drafting language was technical, but the transaction was plain: the page could ask; the browser could refuse. A projector booking did not transfer ownership of the building.

Exit was already part of the design, rather than an apology added after the curtain rose. If the end user instructed the user agent to end a fullscreen session, the draft said to fully exit it. It also allowed a browser message explaining how to leave. The fullscreenchange event gave a page a way to respond when the state changed, including when its own script was not the one that changed it. A player can pause or rearrange controls after an exit; it cannot reasonably assume its request lasts forever.

The paper trail then takes a turn that is easy to miss. W3C's 18 November 2014 Working Group Note says work on that document was discontinued and points to the WHATWG Fullscreen specification instead. The distinction matters. The W3C page did not become a Recommendation, and the feature did not vanish because the W3C document stopped moving. The standards home changed while the problem remained on every screen: how to grant immersion without granting captivity.

The WHATWG living standard makes the modern contract more explicit. requestFullscreen() now returns a promise that resolves when the element is displayed; exitFullscreen() also returns a promise. A request ordinarily needs transient user activation, such as a recent interaction, with a specific exception for a user-generated orientation change. The browser consumes the activation when accepting the request. A site cannot treat fullscreen as a routine side effect of loading a page and expect the same welcome it gives a click on a video player.

The present model still uses a top layer: the document's fullscreen element is the topmost element there with its fullscreen flag set. Its :fullscreen state and backdrop let the browser and page render the scene coherently. The spec defines fullscreenchange and fullscreenerror, so a page can hear both applause and rejection. These are present-day details of the living standard; the 2012 draft used different method signatures and a different description of the entry condition. Two documents fourteen years apart are a history, not one timeless blob of API text.

Embedded content raises the sharpest power question. A video inside an iframe may belong to a third party while the surrounding page belongs to someone else. The living standard's fullscreen permissions-policy feature defaults to 'self'; nested content needs explicit permission, through the iframe's allowfullscreen or allow mechanism, or a suitable policy header. A theater may rent its screen to a visiting act. It still controls who may take over the stage.

And the exit remains outside the act's control. The living standard says user agents should make fullscreen visible to the person, provide an exit that always works, and tell them how to use it. It explains the reason: a fullscreen page could imitate the browser or even the operating system. The browser may end a session whenever it deems that necessary. Those lines are the hinge of the whole story. A page can remove the familiar frame for a film or game; the frame's authority does not disappear with its pixels.

That is why Fullscreen API belongs in the history of the Internet rather than a list of convenient buttons. The standard gave creators a shared way to make the web feel like a cinema, a game console or a presentation room. It also insisted that the venue manager keep the door. The most interesting feature of a darkened theater is often the little green sign everyone hopes they will never need.