HTML prüfen und Fehler finden

Am Ende dieses Kurses steht eine Fähigkeit, die alle anderen absichert: Fehler finden, die nicht wehtun.

01 / 05Der Browser meldet nichts

HTML ist fehlertolerant. Anders als bei einer Programmiersprache bricht nichts ab, wenn du dich vertippst. Der Browser hat für jeden Fehler eine feste Reparaturregel, wendet sie an und zeigt das Ergebnis.

Das ist eine Stärke des Webs: Eine Seite von 1998 mit fünfzig Fehlern lädt heute noch. Für dich beim Schreiben ist es aber ein Problem, denn es gibt keine Rückmeldung.

<ul>
  <li>Linsen
  <li>Suppengrün</li>
  <li>Essig</li>
</ul>

<p>Ein Absatz mit einem <strong>fetten Wort, dessen Tag offen bleibt.</p>
<p>Und der nächste Absatz.</p>

Beim ersten li fehlt das schließende Tag, beim strong ebenfalls, aber nur eins davon ist ein echter Fehler. Bei li ist der Endtag laut Spezifikation auslassbar, wenn direkt das nächste li folgt, der Validator meldet hier also nichts. Beim strong ist der Endtag dagegen Pflicht, und genau das wird zum Problem: Auf der Seite stehen drei Punkte in der Liste, wie erwartet, aber das offene strong wirkt weiter, und der zweite Absatz ist ebenfalls fett.

Was der Browser stattdessen gebaut hat, kannst du ihn fragen. Tipp in der Eingabezeile der Console das hier ab und drück Enter:

document.querySelectorAll("strong").length

Die Antwort ist 2. Du hast ein strong geschrieben, im Dokument stehen zwei. Der Browser konnte das offene Element nicht über den Absatz hinweg offen lassen, also hat er es geschlossen und hinter dem </p> ein neues aufgemacht. Deshalb ist der zweite Absatz fett, obwohl dort kein einziges Tag steht.

Die Zeile ist JavaScript, und das lernst du hier nicht. Für den Moment reicht: Was in den Klammern steht, ist ein CSS-Selektor, und length heißt „wie viele“. Abtippen genügt.

Das ist typisch. Manche Auslassungen sind erlaubt und fallen deshalb nie auf, andere sind echte Fehler und wirken an Stellen, an denen man sie nie vermuten würde.

02 / 05Falsche Verschachtelung

<p>Ein Absatz mit <strong>einem <em>doppelt ausgezeichneten</strong> Wort.</em></p>

<ul>
  <li>Erster Punkt</li>
  <p>Ein Absatz mitten in der Liste</p>
  <li>Zweiter Punkt</li>
</ul>

Zwei Fälle. Oben überlappen sich strong und em: Das strong wird geschlossen, obwohl das em darin noch offen ist. Wie Klammern, die sich kreuzen. Der Browser sortiert das nach eigenen Regeln, und im Dokument steht danach etwas anderes als im Code.

Auch das lässt sich nachfragen. document.querySelector("p").innerHTML gibt dir den Absatz so zurück, wie er nach der Reparatur dasteht, und das ist Ein Absatz mit <strong>einem <em>doppelt ausgezeichneten</em></strong><em> Wort.</em>.

Vergleich das mit dem, was oben im Code steht. Aus einem em sind zwei geworden: Der Browser hat es am </strong> abgeschnitten und dahinter wieder aufgemacht. Das Ergebnis sieht gleich aus und ist eine andere Struktur, und Struktur ist genau das, was ein Screenreader liest.

Genau dieser Satz stand schon in Lektion 1.4, und dort musste die Behauptung reichen. Jetzt siehst du sie.

Unten steht ein p direkt in einer ul. Dort dürfen nur li stehen, du kennst das aus der Listen-Lektion. Hier repariert der Browser aber nichts: Der Absatz bleibt als Kind der Liste stehen, ungültig und ohne jede Meldung. document.querySelectorAll("ul > p").length antwortet 1, und damit ist es belegt.

03 / 05Doppelte id

<p><a href="#kapitel">Zum Kapitel springen</a></p>

<h2 id="kapitel">Erstes Kapitel</h2>
<p>Der Sprung landet hier.</p>

<h2 id="kapitel">Zweites Kapitel</h2>
<p>Und dieses hier wird nie angesprungen.</p>

Beide Überschriften tragen id="kapitel". Der Sprunglink funktioniert und landet beim ersten Treffer. Der zweite Abschnitt ist nie erreichbar, und ein label, das auf diese id zeigt, würde ebenfalls das falsche Element treffen. Auch hier: keine Fehlermeldung, nur ein stiller Fehler.

Zwei Fragen zeigen das Problem in seiner ganzen Breite. document.querySelectorAll("#kapitel").length antwortet 2, es gibt die Kennung also wirklich zweimal. document.getElementById("kapitel").textContent antwortet Erstes Kapitel: Angesprochen wird trotzdem immer nur die erste. Das zweite Kapitel ist da, hat einen Namen und ist unter diesem Namen nicht zu erreichen.

04 / 05Wie du sie trotzdem findest

Der W3C-Validator unter validator.w3.org prüft eine Seite gegen den Standard. Du gibst eine Adresse ein oder lädst eine Datei hoch und bekommst eine Liste mit Zeilennummern. Er ist streng und meldet auch Kleinigkeiten. Genau das ist der Sinn.

Die Eingabezeile der Console, die du oben dreimal benutzt hast. Sie fragt nicht deinen Quelltext, sondern das fertige Dokument, und das ist der ganze Unterschied. Drei Fragen decken die meisten Fälle ab: document.querySelectorAll("...").length zählt, .innerHTML zeigt ein Stück Markup nach der Reparatur, und document.getElementById("...") sagt dir, welches Element bei einer doppelten Kennung wirklich gemeint ist.

Einen aufklappbaren Baum zum Durchblättern gibt es hier nicht, du bekommst immer die Antwort auf deine Frage. In deinem eigenen Browser heißt dieser Baum Elements-Tab und öffnet sich mit F12. Ab der nächsten Lektion arbeitest du dort, dann sieh ihn dir an.

Der Reiter „Netzwerk“ meldet keine HTML-Fehler, zeigt aber jede Datei, die die Seite geholt hat. Ein Bildpfad, den es nicht gibt, steht dort als Zeile mit dem Vermerk „fehlgeschlagen“. Das ist der schnellste Weg zu einem Tippfehler im src.

05 / 05Die häufigsten vier

Zum Merken, weil sie zusammen den Großteil ausmachen:

1. Schließender Tag fehlt, obwohl er Pflicht ist. Saubere Einrückung verrät das oft schon beim Lesen.
2. Falsche Verschachtelung. Was zuerst geöffnet wird, wird zuletzt geschlossen.
3. Fehlendes alt. Der Validator meldet es zuverlässig.
4. Doppelte id. Kommt fast immer durch Kopieren zustande.

Und der Satz, der über allem steht: „Sieht im Browser gut aus“ ist kein Qualitätsnachweis. Es heißt nur, dass die Reparatur ein Ergebnis geliefert hat. Weil die Regeln dafür festgeschrieben sind, bekommst du dasselbe Ergebnis übrigens in jedem Browser: Der falsche Baum entsteht überall, nur merkst du es nirgends. Ob dabei die Struktur herauskam, die du gemeint hast, sagt dir das Bild nicht, und ein Screenreader liest die Struktur, nicht das Bild.