Fehler finden und beurteilen
Bei Java oder Python meldet sich der Übersetzer, wenn etwas nicht stimmt. HTML kennt keine Fehlermeldung. Der Browser nimmt, was er kriegt, rät den Rest und zeigt irgendetwas an.
Das ist bequem und gefährlich zugleich: Ein Fehler fällt nicht auf, wenn du danach suchst – sondern erst, wenn jemand anderes die Seite ganz anders sieht als du.
Der Browser repariert
a) Zähle im Quelltext nach: Wie viele Fehler stecken darin?
b) Öffne die Entwicklerwerkzeuge und sieh im Reiter Elemente nach, was der Browser daraus gemacht hat. Schreibe den reparierten Quelltext ab.
c) Warum ist es trotzdem ein Problem, sich auf diese Reparatur zu verlassen?
Tipp 1
Achte auf Endtags, die fehlen, und auf Endtags, die in der falschen Reihenfolge stehen.
Tipp 2 zu b)
Im Elemente-Reiter siehst du nicht deinen Quelltext, sondern den Baum, den der Browser daraus gebaut hat. Genau darin liegt der Unterschied.
Eindeutig oder mehrdeutig?
Aus der Programmierung kennst du die Forderung, dass eine Handlungsvorschrift eindeutig sein muss: Bei jedem Schritt muss klar sein, was als Nächstes zu tun ist.
Bei HTML gilt dasselbe – für den Quelltext als Beschreibung eines Baums. <div><span>Text</div></span> beschreibt keinen eindeutigen Baum: Steht das span im div oder das div im span? Beides ist ablesbar, und beides kann nicht stimmen.
Der Browser entscheidet sich für eine Deutung, weil er muss. Aber die Vorschrift war mehrdeutig – und damit fehlerhaft, auch wenn am Ende etwas Vernünftiges auf dem Bildschirm steht.
Wo dann der Fehler auffällt
a) Sag vor dem Ansehen voraus, wie die Liste aussehen sollte, wenn sie richtig wäre.
b) Sieh dir die Vorschau an. Wo steht Milch?
c) Finde den Fehler und behebe ihn.
Tipp
Zähle die <ul> und die </ul>. Und zähle sie noch einmal.
Werkzeuge, die doch meckern
Es gibt Programme, die HTML prüfen, statt es zu reparieren. Der bekannteste ist der Validator des W3C unter https://validator.w3.org. Man gibt eine Adresse ein oder lädt eine Datei hoch und bekommt eine Liste aller Verstöße mit Zeilennummer.
Er findet:
- fehlende und falsch geschachtelte Endtags
- Attribute, die es nicht gibt oder die an diesem Element nichts zu suchen haben
- ein
imgohnealt - doppelt vergebene
id-Attribute
Er findet nicht, ob deine Auszeichnung sinnvoll ist. Eine Seite aus lauter <div> ist gültiges HTML.
Quelltexte beurteilen
Drei Gruppen haben denselben Inhalt ausgezeichnet. Alle drei sind gültiges HTML und sehen im Browser fast gleich aus.
Beurteile jede Fassung. Nenne jeweils mindestens einen konkreten Nachteil oder Vorteil.
Fassung A
<div class="gross">Schulgarten</div>
<div>Wir treffen uns dienstags.</div>
<div class="fett">Alle dürfen mitmachen!</div>Fassung B
<h1>Schulgarten</h1>
<p>Wir treffen uns dienstags.</p>
<p><b>Alle dürfen mitmachen!</b></p>Fassung C
<article>
<h1>Schulgarten</h1>
<p>Wir treffen uns <time datetime="2026-03-17">dienstags</time>.</p>
<p><strong>Alle dürfen mitmachen!</strong></p>
</article>Tipp
Prüfe jede Fassung an drei Fragen:
- Erkennt ein Vorleseprogramm die Überschrift?
- Erkennt eine Suchmaschine, worum es geht?
- Wenn du die Schriftgröße der Überschrift ändern willst – wo musst du hin?
So beurteilst du einen HTML-Quelltext:
| Frage | Woran man es sieht |
|---|---|
| Ist er wohlgeformt? | Alle Tags geschlossen, sauber geschachtelt |
| Ist er gültig? | Der Validator meckert nicht |
| Ist er sinnvoll ausgezeichnet? | Es stehen semantische Elemente da, wo es welche gibt |
| Ist er zugänglich? | alt bei Bildern, sprechende Linktexte, lang, richtige Überschriftenstufen |
| Ist er wartbar? | Klassennamen beschreiben die Bedeutung, nicht das Aussehen; sinnvoll eingerückt |
Die ersten beiden sind hart – da gibt es richtig und falsch. Die letzten drei sind Beurteilungen, die man begründen muss.