Ungültiges HTML: welche Fehler Browser verzeihen und welche kosten

Doppelte IDs, offene Tags, verschachtelte Formulare. Die Markup-Fehler, die überleben, weil der Browser sie repariert — und die, die still das Verhalten brechen.

HTML · Veröffentlicht: 8. September 2026 · 3 Min. Lesezeit · Марк Лебедев

Browser sind von Haus aus nachsichtig: Der HTML-Parser hat für nahezu jede fehlerhafte Eingabe ein dokumentiertes Wiederherstellungsverfahren. Diese Nachsicht ist der Grund, warum ungültiges Markup jahrelang überlebt — und warum ein Teil davon echten Schaden anrichtet, ohne dass es jemand bemerkt.

Die Fehler, die wirklich etwas kaputt machen

Doppelte IDs. document.getElementById liefert den ersten Treffer und nur diesen. Ein Label zeigt auf das falsche Feld; ein Skript hängt einen Handler an ein Element, das niemand anklickt. Das ist der häufigste Befund auf komponentenbasierten Websites, weil eine fest im Komponentencode stehende ID in dem Moment zum Duplikat wird, in dem die Komponente zweimal rendert.

Verschachtelte Formulare. HTML erlaubt sie nicht, und der Parser verwirft das innere stillschweigend. Der Submit-Button darin tut dann nichts, und im Editor sieht der Code korrekt aus.

Labels ohne Ziel. for="email" ohne ein id="email" zerstört den Klick auf das Label und nimmt dem Feld seinen zugänglichen Namen — ein Fehler, der Bedienbarkeit und Barrierefreiheit zugleich kostet.

Ineinander verschachtelte interaktive Elemente. Ein Button in einem Link oder ein Link in einem Button erzeugt browserabhängiges Verhalten und unvorhersehbaren Tastaturfokus.

Doppelte Attribute. <input value="a" value="b"> — das zweite wird verworfen, meist genau jenes, das später zur Fehlerbehebung ergänzt wurde.

Die weitgehend kosmetischen Fehler

Ein offenes <li>, ein einzelnes & statt &, ein veraltetes <center>, ein fehlendes type am Skript-Tag. Der Parser bewältigt alles davon, und die gerenderte Seite ist identisch. Sie zu beheben lohnt sich, wenn es billig ist — einen Sprint verdienen sie nicht.

Eine Einschränkung: Offene Tags in Tabellen und Listen verändern die Form des DOM-Baums und nicht nur den Markup-Text — das verschiebt Inhalte auf der Seite. Diese sind ernst zu nehmen.

Warum ein Linter über den Quelltext nicht reicht

Templates werden zur Laufzeit zusammengesetzt. Eine für sich gültige Komponente wird ungültig auf einer Seite, auf der sie zweimal erscheint oder in einem bereits geöffneten Formular steckt. Ihr Linter liest Dateien; der Browser sieht das zusammengesetzte Dokument. Die einzig verlässliche Prüfung läuft über das gerenderte HTML echter Seiten:

für jede gecrawlte seite:
  das ausgelieferte html parsen
  ids, die mehr als einmal vorkommen?
  formulare in formularen?
  label[for] ohne passende id?
  interaktive elemente in interaktiven elementen?

Über die ganze Website ausführen und nach Template gruppieren — wie bei den meisten Markup-Problemen erklärt eine schlechte Komponente hundert schlechte Seiten.

Was das Auslassen kostet

Nichts Dramatisches — und genau das ist das Problem. Ein Formular, das auf einem Template nicht absendet. Ein Screenreader, der das falsche Feld ansagt. Ein Klick-Handler an einem unsichtbaren Duplikat. Jedes sieht nach einem Einzelfehler aus, bekommt ein Ticket, bekommt einen Workaround — und die eigentliche Ursache, drei Zeilen Markup, bleibt liegen und bereitet den nächsten "Einzelfehler" vor.