Was ist eine HTML-Datei?

HTML ist ein reines Textformat, das sich in jedem Editor öffnen lässt. Es kann Bildpunkte und gezeichnete Formen auf derselben Seite halten. Eingesetzt wird es für das Web und die Bearbeitung.

Die Endung lautet .html, der volle Name HyperText Markup Language. Beides sagt weniger aus als das, was die Datei halten kann — und davon handelt der Rest dieser Seite.

Es stammt von WHATWG. Die Spezifikation ist HTML Living Standard.

Das Alter ist aus einem praktischen Grund interessant: je älter ein Format, desto mehr Programme hatten Zeit, es zu lernen.

Sie ist vollständig veröffentlicht, das Format lässt sich also aus dem Dokument umsetzen statt durch Nachsehen. Deshalb taucht es in so vielen Programmen auf, und deshalb gehen Dateien von vor zwanzig Jahren heute noch auf. Veröffentlicht heißt allerdings nicht lizenzfrei: Wo ein Format einen Codec einpackt, ist die Patentfrage eine eigene, die der Standard nicht mitbeantwortet.

Visual Studio Code und Google Chrome lesen es, und die meisten Programme derselben Art ebenfalls.

Wenn eine Datei nicht aufgeht, liegt es selten am Format — häufiger daran, dass das Programm älter ist als das Format. Die Umwandlung in etwas Älteres ist der verlässliche Weg daran vorbei, und dafür gibt es den Rest dieser Website.

Jeder aktuelle Browser liest es.

Damit lässt es sich bedenkenlos auf eine Seite stellen oder an eine Nachricht hängen, ohne sich zu fragen, was die Gegenseite installiert hat.

HTML ist zum Öffnen und Ändern gedacht. Behalte die Datei in diesem Format, solange die Arbeit läuft, und exportiere daraus, wann immer eine fertige Fassung gebraucht wird.

Das ist der eine Punkt, den man bei HTML verstanden haben muss, fast jede Schwierigkeit mit dem Format geht darauf zurück. Eine HTML-Datei enthält den Text und die Struktur — Überschriften, Absätze, Tabellen, Links — und verweist auf alles andere. Das Stylesheet, das sie gestaltet aussehen lässt, ist eine eigene Datei. Ebenso die Bilder, die Schriften, die Skripte und alles, was von einem anderen Server geladen wird.

Eine für sich gespeicherte und später geöffnete HTML-Datei zeigt deshalb den Inhalt ohne jede Gestaltung: unformatierte Überschriften, fehlende Bilder, eine Seite, die aussieht wie 1994. Beschädigt ist nichts. Die Verweise führen schlicht ins Leere, weil das, worauf sie zeigen, nie Teil der Datei war.

Nach den deutschen Grundsätzen zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form müssen geschäftsrelevante E-Mails unverändert, vollständig und über die gesetzliche Frist hinweg lesbar aufbewahrt werden. Eine als HTML-Datei aus dem Postfach exportierte Nachricht erfüllt das nur, wenn wirklich alles mitkommt, worauf sie verweist — eingebettete Logos, verlinkte Bilder, das Stylesheet des Absenders.

Genau das geht beim Exportieren am häufigsten schief: Der Text landet in der Ablage, Bilder und Formatierung bleiben auf dem Mailserver zurück und verschwinden mit ihm. Für die Aufbewahrungspflicht zählt das als unvollständig. Wer HTML-Post rechtssicher archivieren muss, sollte das Werkzeug prüfen, das das gesamte Nachrichtenformat inklusive aller Anhänge sichert, statt die HTML-Ansicht allein zu speichern.

Browser wissen das, deshalb legt das Speichern einer Seite eine HTML-Datei und daneben einen gleichnamigen Ordner an, der die Bilder und Stylesheets enthält. Beide reisen zusammen oder gar nicht — wird nur die HTML per Mail verschickt, bekommt die Empfängerin die unformatierte Version.

Die meisten Browser bieten zusätzlich eine Ein-Datei-Option an, manchmal "Webseite, komplett" oder MHTML genannt, die alles in eine Datei packt. Das löst das Transportproblem und schafft ein neues: Das Ergebnis lässt sich zuverlässig nur in einem Browser derselben Familie lesen. Um eine Seite weiterzugeben, ist PDF das Format, das wirklich funktioniert — eine Datei, alles eingebettet, für jeden gleich.

Ein Dokumentformat umzuwandeln bedeutet meist, eine Struktur auf eine andere abzubilden. HTML nach PDF ist anders: Die Seite muss zuerst layoutet werden, weil nichts in der Datei sagt, wie breit irgendetwas ist. Ein Browser entscheidet das anhand der Fenstergröße, des Stylesheets und der verfügbaren Schriften, und erst dann gibt es Positionen, die sich auf eine Seite setzen lassen.

Deshalb erzeugt dieselbe Seite in unterschiedlichen Werkzeugen unterschiedliche PDFs, und deshalb kann eine Seite, deren Inhalt erst per Skript aufgebaut wird, leer ankommen. Auch deshalb gibt es Druckstylesheets — eine gut gebaute Website hält Regeln dafür vor, wie sie auf Papier aussehen soll, und ein Konverter, der sie respektiert, liefert ein deutlich besseres Ergebnis als einer, der die Bildschirmansicht bloß fotografiert.

E-Mail. Fast jede Marketingnachricht und Benachrichtigung ist HTML, geschrieben gegen eine viel ältere und eigenwilligere Teilmenge als eine Webseite verwendet — Layout-Tabellen, Inline-Stile, nichts von den modernen Möglichkeiten, weil E-Mail-Programme mit Rendering-Kernen arbeiten, deren Weiterentwicklung längst gestoppt wurde. Eine aus einem Mailprogramm exportierte HTML-Datei sieht im Browser deshalb falsch aus, und das ist kein Fehler des Exports.

Dokumentationen und Berichte sind der andere große Anwendungsfall. Alles, was ein Werkzeug automatisch erzeugt — Testergebnisse, Abdeckungsberichte, Analyseexporte, E-Book-Kapitel — ist meist HTML, weil jede Maschine es ohne Lizenzfragen anzeigen kann. EPUB, das E-Book-Format, ist ein ZIP aus HTML-Dateien mit einem Manifest.

Eine HTML-Datei ist Text, jemand muss also festlegen, wie die Buchstaben gespeichert sind, und die Datei erklärt das in einem Meta-Tag am Anfang. Ist diese Angabe falsch, kommen Umlaute, typografische Anführungszeichen und jede nicht-lateinische Schrift als Fragezeichen, schwarze Rauten oder Zeichenpaare ohne Sinn heraus.

UTF-8 ist inzwischen überall die richtige Antwort, und eine Datei ohne diese Angabe wird von dem geraten, was sie öffnet. Sieht eine Seite in einem Browser richtig und in einem anderen verstümmelt aus, liegt es fast immer daran — die Datei ist es, die die Information nicht liefert, nicht der Browser.

Es ist Text, jeder Editor funktioniert. Ein für Code gebauter Editor bringt zwei Dinge mit, die sich lohnen: Er färbt die Tags ein, sodass die Struktur auf einen Blick sichtbar wird, und er meldet ein nicht geschlossenes Element, bevor man zwanzig Minuten damit verbringt, sich zu fragen, warum die halbe Seite fett ist.

Was kein Editor abfängt, ist die Nachsicht des Browsers. HTML hat keinen strengen Parser — eine fehlerhafte Seite wird nicht abgelehnt, sondern nach Regeln repariert, und die Reparatur ist nicht zwangsläufig das Gemeinte. Dass eine Seite richtig aussieht, ist kein Beleg dafür, dass die Auszeichnung richtig ist — dafür gibt es Validatoren.