Zusammenfassung

  • Der W3C-Arbeitsentwurf vom 3. Juli 2012 beschrieb den Vollbildwunsch eines Elements, das Beenden durch das Dokument, die oberste Darstellungsebene und einen vom Nutzer veranlassten Ausgang.
  • 2014 stellte das W3C die Arbeit an diesem Dokument ein und verwies auf WHATWG. Der heutige Standard bindet gewöhnliche Anfragen an eine kurzzeitige Nutzeraktivierung, regelt eingebettete Inhalte und verlangt einen stets funktionierenden Weg hinaus.

Man stelle sich ein Kino vor, dessen Vorführungen von Webseiten organisiert werden. Das Video will das Licht dimmen. Das Spiel beansprucht die gesamte Wand. Die Folien erklären die Browserleiste zum ungebetenen Statisten. Der Saalchef lässt sie gewähren. Dann fragt jemand, wer nach der Vorstellung die Türen öffnet. Eine Frage nach Pixeln ist plötzlich eine Frage nach Zuständigkeit.

Der erste öffentliche W3C-Arbeitsentwurf vom 3. Juli 2012 beschrieb wenige, klare Handgriffe. Ein Element rief requestFullscreen() auf; das Dokument konnte mit exitFullscreen() beenden. fullscreenElement gab Auskunft darüber, was gerade den Bildschirm ausfüllte. Die Methoden lieferten im Entwurf void zurück. Er war ein Working Draft, keine W3C Recommendation. Sein Erscheinungsdatum belegt auch nicht, welcher Browser die Funktion zuerst an sein Publikum brachte.

Ein großes Rechteck konnte eine Seite schon mit CSS zeichnen. Vollbild griff tiefer ein. Der Entwurf legte das Element auf einen Vollbildstapel und in die oberste Ebene des jeweiligen Navigationskontexts, also ganz nach vorn in der Zeichenreihenfolge. Damit wurde festgelegt, was geschieht, wenn Seiteninhalt die gewöhnliche Fenstergrenze überschreitet. Ein besonders selbstbewusstes div besitzt deshalb noch lange nicht den Monitor.

Der Zutritt hatte Bedingungen. Der Entwurf prüfte etwa, ob das Element zu einem Dokument gehörte, ob Vollbild in den beteiligten Kontexten erlaubt war und ob verschachtelte Zustände kollidierten. Außerdem gab es eine damalige Bedingung zur Erlaubnis, ein Pop-up anzuzeigen; bestehende Nutzerwünsche, Sicherheitsbedenken und Plattformgrenzen konnten ebenfalls gegen die Anfrage sprechen. Die Seite stellte einen Antrag. Der Browser konnte ihn ablehnen. Wer die Bühne mietet, kauft nicht gleich das Gebäude.

Der Ausgang war von Anfang an Teil der Konstruktion. Wies der Nutzer den Browser an, eine mit der API begonnene Vollbildsitzung zu beenden, sah der Entwurf einen vollständigen Ausstieg vor. Ein Hinweis auf den Rückweg war ebenfalls möglich. Durch fullscreenchange konnte die Seite erfahren, dass sich der Zustand geändert hatte, und ihre Bedienelemente anpassen. Der Filmvorführer darf merken, dass das Publikum gegangen ist. Es zurück in die Sitze zu zwingen, gehört nicht zum Vertrag.

In der Dokumentgeschichte folgt ein leicht zu übersehender Richtungswechsel. Die W3C-Notiz vom 18. November 2014 erklärt die Arbeit an diesem Dokument für beendet und verweist auf die Fullscreen-Spezifikation der WHATWG. Der Entwurf von 2012 wurde dadurch nicht nachträglich zur Recommendation. Die Funktion verschwand ebenso wenig. Nur die Werkstatt für den laufenden Standard wechselte, während die Frage nach Bühne und Ausgang erhalten blieb.

Der heutige Living Standard der WHATWG formuliert den Eintritt genauer. requestFullscreen() und exitFullscreen() liefern nun Promises. Gewöhnlich setzt eine Anfrage eine kurzzeitige Aktivierung durch den Nutzer voraus, etwa eine unmittelbar vorausgehende Interaktion; eine vom Nutzer ausgelöste Änderung der Bildschirmausrichtung ist als besonderer Fall genannt. Bei Annahme wird die Aktivierung verbraucht. Wer auf „Vollbild“ klickt, hat etwas anderes getan als jemand, dessen gerade geladene Seite sich ungefragt zum Kinobetreiber erklärt.

Das Vollbildelement bleibt an die oberste Ebene gebunden: Es ist dort das oberste Element mit gesetztem Vollbildmerkmal. Mit :fullscreen kann die Darstellung gestaltet werden; fullscreenchange und fullscreenerror melden Änderung beziehungsweise Fehlschlag. Diese heutige Form darf nicht in den Entwurf von 2012 zurückprojiziert werden. Dessen Methoden hatten andere Rückgabewerte und dessen Zutrittsregel wurde anders beschrieben. Standards haben eine Geschichte, auch wenn der Knopf auf dem Bildschirm vertraut aussieht.

Bei eingebetteten Inhalten zeigt sich die Machtfrage besonders deutlich. Darf ein fremdes Video in einem iframe eigenständig den gesamten Bildschirm belegen? Die heutige Berechtigungsrichtlinie behandelt fullscreen als kontrollierte Funktion und setzt die Standard-Erlaubnisliste auf 'self'. Verschachtelte Inhalte benötigen eine ausdrückliche Erlaubnis über allowfullscreen, allow oder einen passenden Richtlinien-Header. Ein Theater kann einer Gastgruppe die Bühne anbieten. Die Gebäudeschlüssel verteilt weiterhin der Hausherr.

Auch die grüne Lampe über dem Ausgang hat eine technische Begründung. Der aktuelle Standard verlangt, dass der Browser den Vollbildzustand erkennbar macht und einen immer funktionierenden Ausstieg anbietet und erklärt. Eine Vollbildseite kann die Oberfläche des Browsers oder sogar des Betriebssystems nachahmen. Der Browser darf eine Sitzung bei Bedarf selbst beenden. Das Publikum soll wissen, dass es noch in einer Vorstellung sitzt, selbst wenn die Bühne wie das gesamte Haus aussieht.

Fullscreen machte aus dem Web einen Ort für Filme, Spiele, Karten und Vorträge. Sein historischer Wert liegt in der gemeinsamen Erlaubnis, groß aufzutreten, und der ebenso gemeinsamen Regel, wieder klein werden zu müssen. Das Bild darf die Wand füllen. Die Tür bleibt sichtbar.