Zusammenfassung

  • Ein W3C-Entwurf zu HTML 5 vom April 2009 beschrieb pushState() zum Anlegen eines Eintrags mit Zustand und popstate beim Aktivieren eines gespeicherten Eintrags. Auch Ansichten in einem Dokument konnten im Rückweg liegen.
  • Die HTML5-Empfehlung von 2014 beschrieb zusätzlich replaceState() und zeigte ein Spiel, das nach Zurück seine Anzeige aus event.state wieder aufbaute. Der Browser verwahrte die Karte; die Seite baute die Kulisse.

Der Zurück-Knopf hatte seine Aufgabe erfüllt. Er war beim vorherigen Verlaufseintrag angekommen. Die Seite stand noch im Kostüm der nächsten Szene auf der Bühne und tat überrascht. Das Publikum schimpfte über den Knopf. Der Browser hatte die richtige Karte. Die Anwendung hatte die Kulisse verlegt.

Der Unterschied fiel auf, als Websites einzelne Ansichten veränderten, ohne bei jedem Schritt ein neues Dokument zu laden. Eine Galerie sprang zum nächsten Bild, eine Suche tauschte Ergebnisse aus, eine Karte wanderte in einen anderen Stadtteil. Die Anzeige änderte sich, die Adresse konnte gleich bleiben. Dann drückte ein Leser Zurück und erwartete das vorige Foto, die vorige Ergebnisliste oder den alten Kartenausschnitt. Hatte die Seite für diesen Schritt keinen Verlaufseintrag angelegt, führte der Browser anderswohin. Seine Erinnerung an Schritte musste mit der Erinnerung der Anwendung an Ansichten verbunden werden.

Der W3C-Arbeitsentwurf zu HTML 5 vom 23. April 2009 beschrieb die Verbindung. Das History-Interface umfasste back, forward und go. pushState(data, title, url) legte einen Eintrag mit Zustand im Sitzungsverlauf an; beim erneuten Aktivieren eines solchen Eintrags wurde popstate ausgelöst. Eine Ansicht innerhalb desselben Dokuments konnte dadurch eine Adresse und einen gespeicherten Zustand erhalten. Für den Browser entstand ein Weg durch Veränderungen, die zuvor nur die Anwendung kannte.

Der Entwurf benutzte das Beispiel eines Spiels, dessen Position sich als Adresse speichern ließ. Die Spielfigur bewegt sich; die Seite zeichnet die neue Stelle; Adresse und Verlaufseintrag wandern mit. Bei Zurück findet der Browser den Zustand einer früheren Station. Das Spiel muss die Figur dort zeichnen. Der Browser bewahrt eine Eintrittskarte auf, aber er baut das Spielfeld nicht allein aus der Erinnerung wieder auf. Dafür gibt es den Bühnenarbeiter der Seite.

Ob eine Station hinzugefügt oder die gegenwärtige geändert wird, prägt den Rückweg. In der W3C-Empfehlung HTML5 vom 28. Oktober 2014 fügt pushState() einen Eintrag hinzu; replaceState() aktualisiert den aktuellen. Eine bedeutsame Ansicht, zu der jemand zurückkehren möchte, verdient eine neue Stufe. Eine Korrektur der laufenden Ansicht kann auf derselben bleiben. Würde jeder Tastendruck einen Eintrag erzeugen, wäre Zurück eine Wanderung. Gäbe es für wichtige Ansichten keinen, überspränge der Knopf die Arbeit des Lesers.

Das Dokument von 2014 zeigt ein kleines Spiel auf einer Linie. Ändert sich die Position, ruft es history.pushState(...) auf. Beim Durchlaufen des Verlaufs führt sein onpopstate-Handler setupPage(event.state) aus und richtet die Anzeige neu ein. Das Beispiel braucht nur wenige Zeilen, zeigt aber die ganze Arbeitsteilung. Der Browser wählt den Eintrag, die Anwendung stellt die dazugehörige Szene her. Eine korrekte URL über dem falschen Bildschirm ist ein Spielplan an der Tür zum falschen Theaterstück.

Auch die Adresse hatte eine Grenze. Die Empfehlung von 2014 prüfte, ob die neue URL zum aktuellen Dokument passte. Das gegenwärtige Kapitel des lebenden HTML-Standards der WHATWG zu Navigation und Verlauf legt weiterhin Bedingungen für das Umschreiben der Adresse fest. Bei HTTP- und HTTPS-Seiten dürfen Pfad, Abfrage und Fragment innerhalb dieses Rahmens wechseln. Eine Seite kann sich mit einem Methodenaufruf keinen fremden Hostnamen anheften. Die Adresse soll der Ansicht folgen und trotzdem eine ehrliche Adresse bleiben.

Der gespeicherte Zustand ist ein Zettel zwischen zwei Arbeitsplätzen. Der Browser legt den Wert zum Verlaufseintrag. Die Anwendung bestimmt seine Bedeutung: ausgewählter Reiter, Kartenposition oder Kennung einer Karte. Wenn der Leser zurückgeht, liefert popstate die Information an die Seite. Ignoriert die Seite sie, erzählen Adresszeile und Anzeige verschiedene Geschichten. Das Archiv des Browsers ist in Ordnung; der Bühnenarbeiter hat sein Stichwort verpasst.

Die API übergab der Website nicht den Zurück-Knopf des Lesers. Der Leser betätigt ihn, und der Browser durchläuft den Sitzungsverlauf. Die Seite entscheidet, wann ein interner Wechsel einen Eintrag verdient, welche Daten daran hängen und wie eine wieder aktive Ansicht gezeichnet wird. Diese kleine Zusammenarbeit gab einer Seite, die sich im Innern dauernd verändert, einen vertrauten Rückweg.

Der Entwurf von 2009 und die Empfehlung von 2014 zeigen zwei Stationen dieser Vereinbarung. Der frühe Text kannte bereits das Anlegen von Zustandseinträgen. Der spätere beschrieb Hinzufügen und Ersetzen gemeinsam und zeigte, wie die Anzeige nach einem Verlaufsereignis wieder aufgebaut wird. Die WHATWG hält die klassischen Methoden in ihrem umfassenderen Navigationsmodell fest. Das Wesentliche ist keine neue Form des Pfeils. Der Browser merkt sich die Reihenfolge der Szenen; die Seite merkt sich, wie jede aussieht.

Für Leser ist die Erwartung alt und einfach: Zurück soll mich dorthin bringen, wo ich eben war. Die History API gab dynamischen Seiten ein Mittel, das ohne neues Dokument bei jedem Wechsel einzulösen. Wenn der Knopf den richtigen Eintrag fand und die Seite in der falschen Szene blieb, war der Knopf der einzige Darsteller, der seinen Text beherrschte.