HTML-Formatierer

Der Großteil von HTML toleriert, dass ein Formatierer seine Leerzeichen frei neu ordnet — zusätzliche Einrückung zwischen Blockelementen wie `<div>` und `<p>` hat keinen sichtbaren Effekt, weil Browser Leerzeichenfolgen zwischen diesen Elementen beim Rendern zusammenfallen lassen. Drei spezifische Fälle brechen diese Annahme vollständig: Inhalt innerhalb von `<pre>` rendert jedes Leerzeichen und jeden Zeilenumbruch wörtlich, exakt wie geschrieben; `<textarea>` behandelt seinen Inhalt genauso, da es gedacht ist, exakten, vom Nutzer editierbaren Text wiederzugeben; und jedes Element mit `white-space: pre` in CSS erbt dieselbe wörtliche Behandlung. Ein Formatierer, der Leerzeichen innerhalb eines dieser Blöcke neu ordnet, ändert, was die Seite tatsächlich anzeigt, nicht nur wie der Quellcode aussieht — deshalb lässt dieser Formatierer sie vollständig unangetastet, statt seine üblichen Einrückungsregeln anzuwenden.

Inline-Elemente direkt neben Text sind ein subtilerer Fall: Ein Leerzeichen zwischen zwei Inline-Elementen ist manchmal visuell bedeutsam — das Leerzeichen zwischen zwei Wörtern, die über separate `<span>`-Tags verteilt sind, zum Beispiel — daher ist der Formatierer bei Inline-Inhalt bewusst konservativ und lässt mehrdeutige Leerzeichen lieber so, wie sie sind, statt zu riskieren, ein Leerzeichen zusammenfallen zu lassen, das echte visuelle Arbeit leistete.

Eine als einzelne HTML-Datei zusammengesetzte Seite bettet häufig ihr eigenes CSS in einen `<style>`-Block und ihr eigenes JavaScript in einen `<script>`-Block ein, und ein Formatierer, der nur HTML-Tags versteht, würde diesen eingebetteten Code als unformatierten Block belassen oder, schlimmer, ihn verderben, indem er geschweifte Klammern und Semikolons als HTML-Syntax behandelt. Den Inhalt dieser Blöcke an einen echten CSS-Parser bzw. echten JavaScript-Parser zu übergeben bedeutet, dass die gesamte Datei — Markup, Styles und Verhalten zusammen — konsistent formatiert zurückkommt, statt nur die äußere HTML-Struktur.

Browser sind mit einem Fehlerbehebungsmodell gebaut, das speziell dafür entworfen ist, selbst aus schwer fehlerhaftem Markup etwas Vernünftiges zu rendern — ein nicht geschlossenes Tag, ein fehlendes Anführungszeichen, in ungültiger Reihenfolge verschachtelte Elemente — weil das Web jahrzehntealtes, unvollkommenes HTML in Produktion hat, das trotzdem angezeigt werden muss. Ein Formatierer kann sich dieselbe Nachsicht nicht leisten: Um ein Dokument neu zu formatieren, muss er ein präzises strukturelles Verständnis davon aufbauen, was in was verschachtelt ist, und ein Dokument mit wirklich unausgeglichenen Tags hat keine einzige korrekte Struktur zum Wiederherstellen. Deshalb kann eine Seite, die sich in einem Browser völlig normal anzeigt, trotzdem von diesem Formatierer abgelehnt werden — der Browser hat die Mehrdeutigkeit still auf seine eigene Weise repariert, während ein Tool, das korrekt neu formatieren will, die Mehrdeutigkeit melden muss statt zu raten.

Eine Datei, die beim Formatieren scheitert, ist sehr oft überhaupt kein beschädigtes HTML, sondern ein Template — Handlebars, Jinja, Blade, EJS oder Ähnliches — das Template-Direktiven mit Markup mischt und ein Dokument erzeugt, das für sich genommen kein gültiges eigenständiges HTML ist und das nie sein muss. Das Template wird erst zu echtem, wohlgeformtem HTML, nachdem seine Template-Engine läuft und echte Daten substituiert. Die gerenderte Ausgabe zu formatieren, erfasst nach der Verarbeitung durch die Template-Engine — aus der „Seitenquelltext anzeigen"-Funktion eines Browsers, zum Beispiel — vermeidet das vollständig, da diese Ausgabe echtes HTML ohne verbleibende Template-Syntax ist.