Anlässlich der der Ankündigung, dass der Firefox 4 erstmals standardmäßig einen HTML5-Parser verwenden wird (für Webkit wird auch bereits einer entwickelt), erreichten mich diverse Fragen was das denn jetzt bedeuten würde. Wenn die Browser von heute keinen HTML5-Parser verwenden, was haben sie denn dann? Immerhin können die doch alle – mit Ausnahme des IE – HTML5-Elemente wie <canvas> und <video> darstellen, oder? Richtig ist, dass ein Oldschool-HTML-Parser und ein Parser nach den Regeln der HTML5-Spezifikation sehr viel gemeinsam haben und die wenigen Unterschiede nur selten sichtbar werden. Aber ganz überflüssig sind HTML5-Parser natürlich nicht.

Der Ist-Zustand

Die ersten kommerziellen Browser hatten das Problem, dass HTML als eine SGML-Anwendung konzipiert ist und eigentlich einen sehr komplexen Parser benötigt (SGML ist so etwas wie ein komplizierterer Vorfahre von XML). Für den Einbau eines SGML-Parsers hatte man damals mitten im Browserkrieg aber keine Zeit und so entwickelt man eigene, nicht dem dem Standard entsprechende Parser für HTML-Dokumente. Sie zeichneten sich durch eine hohe Fehlertoleranz aus und bewährten sich letztendlich – jeder moderne Browser verwendet heute zur Verarbeitung von HTML solche Nichtstandard-HTML-Parser.

Im Bemühen um größtmögliche Kompatibilität glichen die Kombattanten des Browserkriegs ihre jeweiligen Implementierungen miteinander ab, so dass also heute alle Browser ungefähr gleich weit von den Standards entfernte Parser haben. HTML5 löst dieses „Problem“, indem einfach die bestehende Parser-Realität zum Standard erhoben und nur minimal erweitert wird. Das funktioniert recht gut, weil zwischen den Browsern bereits Kompatibilität besteht und es relativ wenige Neuerungen gibt.

Was gibt es neues?

Das, was in den HTML5-Spezifikationen über Parser festgelegt wird, entspricht in weiten Teilen dem, was jeder Browser schon heute kann. Anders gesagt: So viel neues gibt es da gar nicht, denn ein HTML5-Element wie <canvas> unterscheidet sich ja, was die Verarbeitung des HTML angeht, nicht fundamental von einem <div>. Die mit dem Element stattfindenden Interaktionen durch den Nutzer sind vielleicht andere, aber letztlich sind beide nicht mehr als eine Node im DOM-Tree und ein Rechteck auf dem Bildschirm.

Die Parser-Realität anzuerkennen und den Ist-Zustand zu standardisieren bringt Zweierlei: Erstens ist es den Browserherstellern möglich, Ihre Implementierungen weiter aneinander anzupassen, sofern es noch nach Jahren des Abschreibens noch Differenzen gibt. Und zweitens gibt es einige wenige Parser-relevante HTML5-Features wie etwa das <math>-Element und Inline-SVG:

<p>
    Das hier ist Inline-SVG:
    <svg width="250" height="50">
        <rect width="250" height="50" fill="green" stroke="black" stroke-width="8" />
    </svg>
</p>
Inline-SVG

Solcherlei Extravaganzen, wie in diesem Fall die Einbettung in XML in HTML, funktionieren nur mit einem HTML5-Parser. Normale neue Elemente wie <canvas> und <section> sind von der Parser-Frage nicht betroffen, weil sie für den bloßen Aufbau eines Dokuments keine besondere Bedeutung haben. Hiervon ausgenommen ist der Internet Explorer < 9, der aufgrund seiner etwas anderen HTML-Verarbeitung mit unbekannten Elementen noch so seine Probleme hat.

HTML5-Parser jenseits des Firefox 4

Der HTML5-Parser wird zwar erstmals im Firefox 4 standardmäßig aktiviert sein, doch vorhanden ist er auch schon in Version 3.6. Dort kann man ihn aktivieren, indem man unter about:config den Schlüssel html5.enable auf true stellt. Wirklich etwas davon haben wird man nur, wenn man Seiten ansteuert, die entsprechende Features auch verwenden – sieht man einmal von möglichen Abstüzen der experimentellen Software ab.

Wer selbst ein Projekt mit HTML5-Parser anschieben möchte findet beim html5lib-Projekt Implementierungen in Python und PHP. Eine Java-Implementierung, die auch Basis des Firefox-Parsers ist, stellt validator.nu bereit.