Debugging HTML

Beim Schreiben von irgendeiner Art von Code läuft alles gut, bis zu dem gefürchteten Moment, wenn ein Fehler auftritt — Sie haben etwas falsch gemacht, also funktioniert Ihr Code nicht — entweder gar nicht oder nicht ganz so, wie Sie es wollten. Zum Beispiel zeigt das Folgende einen Fehler, der auftritt, wenn versucht wird, ein einfaches Programm in der Rust-Sprache zu kompilieren.

Hier ist die Fehlermeldung relativ leicht zu verstehen — "unterbrochene doppelte Anführungszeichen in Zeichenfolge". Wenn Sie das Listing ansehen, können Sie wahrscheinlich sehen, dass println!(Hello, world!"); logisch ein doppeltes Anführungszeichen fehlen könnte. Allerdings können Fehlermeldungen schnell komplizierter und weniger leicht zu interpretieren werden, je größer die Programme werden, und selbst einfache Fälle können für jemanden, der nichts über Rust weiß, etwas einschüchternd wirken.

Debugging muss jedoch nicht beängstigend sein — der Schlüssel, um sich beim Schreiben und Debuggen von Code wohlzufühlen, ist die Vertrautheit mit der Sprache und den zugehörigen Werkzeugen.

HTML ist nicht so kompliziert zu verstehen wie Rust. HTML wird vor dem Parsen nicht in eine andere Form kompilieren (es wird interpretiert, nicht kompiliert). Und die Element-Syntax von HTML ist vermutlich viel leichter zu verstehen als eine "echte Programmiersprache" wie Rust, JavaScript oder Python.

Die Art und Weise, wie Browser HTML parsen, ist viel nachsichtiger als die Art und Weise, wie die meisten Programmiersprachen geparst werden, was sowohl eine gute als auch eine schlechte Sache ist.

Aber was meinen wir eigentlich mit nachsichtig? Nun, im Allgemeinen gibt es zwei Hauptarten von Fehlern, die Sie bei einem Code finden, wenn Sie etwas falsch machen:

• Syntaxfehler: Das sind Tippfehler in Ihrem Code, die dazu führen, dass das Programm nicht ausgeführt wird, wie der Rust-Fehler, der zuvor gezeigt wurde. Diese sind in der Regel leicht zu beheben, solange Sie mit der Syntax der Sprache vertraut sind und wissen, was die Fehlermeldungen bedeuten.
• Logikfehler: Das sind Fehler, bei denen die Syntax eigentlich korrekt ist, aber der Code nicht das tut, was Sie beabsichtigt haben, was bedeutet, dass das Programm falsch läuft. Diese sind oft schwieriger zu beheben als Syntaxfehler, da es keine Fehlermeldung gibt, die Sie auf die Quelle des Fehlers hinweist.

HTML selbst leidet nicht unter Syntaxfehlern, weil Browser es nachgiebig parsen, was bedeutet, dass die Seite immer noch angezeigt wird, selbst wenn es Syntaxfehler im Quellcode gibt. Browser haben integrierte Regeln, um anzugeben, wie sie inkorrekt geschriebenes HTML-Markup (oft als ungültiges oder schlecht geformtes Markup bezeichnet) interpretieren, und es automatisch in gültiges Markup ändern.

Zum Beispiel enthält das folgende HTML-Snippet falsch verschachtelte Elemente:

<p>I didn't expect to find the <em>next-door neighbor's <strong>cat</em></strong> here!</p>

Das schließende </strong>-Tag sollte vor dem schließenden </em>-Tag sein, aber es ist nicht — es ist danach.

Wenn Sie dieses HTML in einen Browser laden und dann den gerenderten DOM betrachten, sehen Sie, dass die Verschachtelung vom Browser korrigiert wurde:

<p>
  I didn't expect to find the
  <em>next-door neighbor's <strong>cat</strong></em> here!
</p>

Warum ist das sowohl gut als auch schlecht? Nun, in diesem Fall hat der Browser das beabsichtigte Ergebnis erstellt, aber wie Sie später sehen werden, ist das nicht immer der Fall. Sie erhalten immer etwas, das funktioniert, aber der Browser bekommt es nicht immer richtig hin, was Probleme verursachen kann. Es ist besser, von Anfang an korrektes Markup zu schreiben.

Wie findet man also Markup-Fehler? Später zeigen wir Ihnen, wie Sie mit einem Tool namens HTML-Validator Fehler in HTML finden können, aber zuerst zeigen wir Ihnen, wie Sie Ihr HTML manuell mit einem DOM-Inspektor inspizieren können, und dann, welche Arten von Markup-Fehlern Sie suchen könnten und wie der Browser diese interpretieren könnte.

Alle modernen Browser verfügen über einen Satz von Entwicklerwerkzeugen (Devtools), die in sie integriert sind, und bieten eine Reihe von Funktionen zum Untersuchen der Webseite, die in die aktuelle Registerkarte geladen ist. Diese können Ihnen zeigen, welches HTML auf der Seite gerendert wird, welches CSS auf jeden DOM-Knoten angewendet wird, welches JavaScript auf der Seite ausgeführt wird und mehr. Sie ermöglichen es Ihnen auch, den aktuell laufenden Code zu bearbeiten und die Wirkung live auf der Seite zu sehen.

Sie können die Devtools auf ähnliche Weise in jedem Browser öffnen — siehe How to open the devtools in your browser, um zu erfahren, wie das geht.

Für diesen Artikel ist die einzige relevante Devtools-Funktion der DOM-Inspektor, der das aktuell gerenderte HTML-DOM anzeigt und es Ihnen ermöglicht, es zu bearbeiten. Schauen wir uns das jetzt an:

1. Öffnen Sie die Devtools in Ihrem Browser.
2. Öffnen Sie den DOM-Inspektor. Er befindet sich an derselben Stelle in jedem Browser — die erste Registerkarte in den Devtools am Anfang der Reihe. In Firefox ist es mit Inspector beschriftet, während es in Safari, Edge und Chrome mit Elements beschriftet ist. Dies sollte die Registerkarte sein, die standardmäßig ausgewählt wird, wenn Sie die Devtools zuerst öffnen, aber wählen Sie sie aus, wenn sie es nicht ist.
3. Untersuchen Sie die DOM-Baumstruktur, die in der Registerkarte angezeigt wird, und beachten Sie, wie Sie auf die kleinen Erweiterungspfeile am Anfang jedes DOM-Knotens klicken können, um sie zu erweitern und ihre Nachfahrenknoten anzuzeigen. Sie können auch die Aufwärts- und Abwärtspfeiltasten verwenden, um nach oben und unten durch die Knoten zu navigieren, und die rechte und linke Pfeiltaste, um die Knoten zu erweitern und zu reduzieren.
4. Versuchen Sie auch, über die Knoten zu fahren (oder sie mit den Pfeiltasten auszuwählen) und beachten Sie, wie das aktuell markierte (oder ausgewählte) Element im Viewport hervorgehoben ist.
5. Sie können auch den gerenderten DOM bearbeiten. Wir werden die Bearbeitungsfunktion in diesem Artikel nicht verwenden, aber nehmen Sie sich etwas Zeit, um nachzuschlagen, wie das geht, wenn Sie interessiert sind.

In diesem Abschnitt werden Sie ein wenig Code using the DOM-Inspektor untersuchen und sehen, wie der Browser mit gängigen Markup-Fehlern umgeht.

1. Speichern Sie zunächst die folgende HTML-Datei als debug-example.html irgendwo auf Ihrem lokalen Computer. Diese Demo ist absichtlich mit einigen eingebauten Fehlern geschrieben, die wir erkunden können.

   html

   <!DOCTYPE html>
   <html lang="en-US">
     <head>
       <meta charset="utf-8">
       <title>HTML debugging examples</title>
     </head>
   
     <body>
       <h1>HTML debugging examples</h1>
       <p>What causes errors in HTML?
       <ul>
         <li>Unclosed elements: If an element is <strong>not closed properly,then its effect can spread to areas you didn't intend
         <li>Badly nested elements: Nesting elements properly is also very important for code behaving correctly. <strong>strong <em>strong emphasized?</strong> what is this?</em>
         <li>Unclosed attributes: Another common source of HTML problems. Let's look at an example: <a href="https://www.mozilla.org/>link to Mozilla homepage</a>
       </ul>
     </body>
   </html>
   

2. Öffnen Sie sie anschließend in einem Browser. Sie werden etwas wie dieses sehen:

3. Das sieht sofort nicht gut aus; lassen Sie uns den Quellcode betrachten, um zu sehen, ob wir herausfinden können, warum (nur der Inhalt des Bodys wird gezeigt):

   html

   <h1>HTML debugging examples</h1>
   
   <p>What causes errors in HTML?
   
   <ul>
     <li>Unclosed elements: If an element is <strong>not closed properly,
         then its effect can spread to areas you didn't intend
   
     <li>Badly nested elements: Nesting elements properly is also very important
         for code behaving correctly. <strong>strong <em>strong emphasized?</strong>
         what is this?</em>
   
     <li>Unclosed attributes: Another common source of HTML problems. Let's
         look at an example: <a href="https://www.mozilla.org/>link to Mozilla
         homepage</a>
   </ul>
   

4. Lassen Sie uns die Probleme überprüfen:

   • Die paragraph- und list item-Elemente haben keine Schlusstags. Beim Blick auf das oben gezeigte Bild scheint dies nicht allzu stark die Darstellung des Markup beeinträchtigt zu haben, da leicht zu erkennen ist, wo ein Element enden und ein anderes beginnen soll.
   • Das erste <strong>-Element hat kein Schlusstag. Dies ist problematischer, da nicht leicht zu erkennen ist, wo das Element enden soll. Tatsächlich wurde der ganze Rest des Textes fett formatiert dargestellt.
   • Dieser Abschnitt ist schlecht verschachtelt: <strong>fett <em>fett betont?</strong> was ist das?</em>. Es ist aufgrund des vorherigen Problems nicht leicht zu erkennen, wie dies interpretiert wurde.
   • Der href-Attributwert fehlt ein schließendes Anführungszeichen. Dies scheint das größte Problem verursacht zu haben — der Link wurde überhaupt nicht gerendert.

5. Lassen Sie uns nun den gerenderten DOM im Gegensatz zum Quellcode untersuchen. Um dies zu tun, öffnen Sie den DOM-Inspektor Ihres Browsers. Sie werden eine Darstellung des gerenderten Markups sehen:

6. Sehen Sie sich an, wie der Browser versucht hat, unsere HTML-Fehler zu beheben (wir haben die Überprüfung in Firefox durchgeführt; andere moderne Browser sollten dasselbe Ergebnis liefern):

   • Die Absätze und Listenelemente haben Schlusstag hinzugefügt bekommen.

   • Es ist nicht klar, wo das erste <strong>-Element geschlossen werden sollte, daher hat der Browser jeden separaten Textblock in sein eigenes <strong>-Element gewickelt, ganz bis zum Ende des Dokuments!

   • Die falsche Verschachtelung wurde vom Browser wie hier gezeigt behoben:

     html

     <strong>
       strong
       <em>strong emphasized?</em>
     </strong>
     <em> what is this?</em>
     

   • Der Link mit dem fehlenden Anführungszeichen wurde vollständig gelöscht. Das letzte Listenelement sieht so aus:

     html

     <li>
       <strong>
         Unclosed attributes: Another common source of HTML problems. Let's look
         at an example:
       </strong>
     </li>
     

Sie können aus dem obigen Beispiel sehen, dass Sie wirklich sicherstellen möchten, dass Ihr HTML gut geformt ist! Aber wie? In einem kleinen Beispiel wie dem oben gesehenen ist es einfach, durch die Zeilen zu suchen und die Fehler zu finden, aber was ist, wenn es sich um ein riesiges, komplexes HTML-Dokument handelt?

Das Werkzeug dafür ist der Markup Validation Service (oder HTML-Validator), der vom W3C erstellt und gepflegt wird (das Sie im Webstandardsmodell kennengelernt haben). Der Validator nimmt ein HTML-Dokument als Eingabe, geht es durch und gibt Ihnen einen Bericht, um Ihnen zu sagen, was an Ihrem HTML nicht stimmt.

Um das HTML zu spezifizieren, das validiert werden soll, können Sie eine Webadresse angeben, eine HTML-Datei hochladen oder direkt HTML-Code eingeben.

In dieser Aufgabe lassen wir Sie den HTML-Validator ausprobieren. Sie validieren unser Beispieldokument und sehen, welche Ergebnisse zurückgegeben werden. Dieses Beispiel enthält das gleiche HTML, das Sie zuvor mit dem DOM-Inspektor untersucht haben.

1. Laden Sie zuerst den Markup Validation Service in einem neuen Browser-Tab, falls er nicht bereits geöffnet ist.
2. Wechseln Sie zur Tab-Validierung per Direkt-Eingabe.
3. Kopieren Sie den gesamten Code des Beispieldokuments (nicht nur den Body) und fügen Sie ihn in das große Textfeld des Markup Validation Service ein.
4. Drücken Sie die Prüfen-Taste.

Dies sollte Ihnen eine Liste von Fehlern und anderen Informationen liefern.

Die Fehlermeldungen sind normalerweise hilfreich, manchmal sind sie jedoch nicht so leicht zu verstehen. Mit ein wenig Übung können Sie lernen, diese zu interpretieren, um Ihren Code zu beheben. Lassen Sie uns die Fehlermeldungen durchgehen und sehen, was sie bedeuten. Sie werden sehen, dass jede Meldung mit einer Zeilen- und Spaltennummer versehen ist, die Ihnen hilft, den Fehler leicht zu lokalisieren.

• "End tag li implied, but there were open elements" (2 Instanzen): Diese Meldungen zeigen an, dass ein Element geöffnet ist, das geschlossen werden sollte. Das End-Tag ist impliziert, aber nicht wirklich vorhanden. Die Zeilen/Spalten-Informationen verweisen auf die erste Zeile nach der Zeile, in der das Schlusstag wirklich sein sollte, aber dies ist ein guter Hinweis darauf, was falsch ist.

• "Unclosed element strong": Dies ist leichter zu verstehen — ein <strong>-Element ist nicht geschlossen, und die Zeilen-/Spalten-Informationen zeigen genau auf, wo es sich befindet.

• "End tag strong violates nesting rules": Dies weist auf die falsch verschachtelten Elemente hin, und die Zeilen-/Spalten-Informationen markieren, wo sie sich befinden.

• "End of file reached when inside an attribute value. Ignoring tag": Diese ist etwas kryptisch; sie bezieht sich auf den Umstand, dass ein Attributwert nicht ordnungsgemäß formatiert ist, möglicherweise nahe dem Ende der Datei, da das Ende der Datei innerhalb des Attributwerts erscheint. Die Tatsache, dass der Browser den Link nicht rendert, sollte Ihnen einen guten Hinweis geben, welches Element nicht richtig ist.

• "End of file seen and there were open elements": Dies ist etwas zweideutig, bezieht sich aber im Grunde genommen darauf, dass es offene Elemente gibt, die ordnungsgemäß geschlossen werden müssen. Die Zeilennummern verweisen auf die letzten Zeilen der Datei, und diese Fehlermeldung wird mit einer Codezeile angezeigt, die ein Beispiel für ein offenes Element zeigt:

  example: <a href="https://www.mozilla.org/>link to Mozilla homepage</a> ↩ </ul>↩ </body>↩</html>
  

  Hinweis: Ein Attribut ohne abschließendes Anführungszeichen kann zu einem offenen Element führen, da der Rest des Dokuments als Inhalt des Attributs interpretiert wird.

• "Unclosed element ul": Dies ist nicht sehr hilfreich, da das <ul>-Element korrekt geschlossen ist. Dieser Fehler tritt auf, weil das <a>-Element aufgrund des fehlenden abschließenden Anführungszeichens nicht geschlossen ist.

Wenn Sie nicht herausfinden können, was jede Fehlermeldung bedeutet, machen Sie sich keine Sorgen. Eine gute Strategie ist es, einige Fehler auf einmal zu beheben und dann Ihr HTML nach jedem Satz von Korrekturen erneut zu validieren, um zu sehen, welche Fehler noch übrig sind. Manchmal wird beim Beheben eines früheren Fehlers auch andere Fehlermeldungen beseitigt — mehrere Fehler können oft durch ein einziges Problem verursacht werden, das einen Dominoeffekt verursacht.

Sie wissen, dass alle Fehler behoben sind, wenn Sie ein kleines grünes Banner sehen, das Ihnen mitteilt, dass es keine Fehler zu berichten gibt. Zum Zeitpunkt des Schreibens stand dort: "Dokumentenprüfung abgeschlossen. Keine Fehler oder Warnungen zu zeigen."

Das war also ein Einstieg in das Debuggen von HTML, der Ihnen einige nützliche Fähigkeiten vermitteln sollte, auf die Sie beim Debuggen von HTML aber auch CSS- und JavaScript-Code im späteren Verlauf des Kurses zurückgreifen können. Dies markiert auch das Ende des Moduls Strukturierung von Inhalten mit HTML.

• Zurück
• Übersicht: Strukturierung von Inhalten mit HTML
• Weiter