Debugging HTML

Beim Schreiben von Code ist alles in Ordnung, bis zu diesem gefürchteten Moment, in dem ein Fehler auftritt – Sie haben etwas falsch gemacht, sodass Ihr Code nicht funktioniert – entweder überhaupt nicht oder nicht ganz so, wie Sie es wollten. Zum Beispiel zeigt das Folgende einen Fehlerbericht beim Versuch, ein einfaches Programm in der Rust Sprache zu kompilieren.

Hier ist die Fehlermeldung relativ leicht zu verstehen – "unterminated double quote string". Wenn Sie sich den Code ansehen, können Sie wahrscheinlich sehen, wie println!(Hello, world!"); möglicherweise ein Anführungszeichen fehlt. Fehlermeldungen können jedoch schnell komplizierter und weniger leicht zu interpretieren werden, wenn Programme größer werden, und selbst einfache Fälle können für jemanden, der nichts über Rust weiß, einschüchternd wirken.

Debugging muss jedoch nicht beängstigend sein – der Schlüssel, um sich mit dem Schreiben und Debuggen jeglichen Codes wohlzufühlen, ist die Vertrautheit mit der Sprache und den dazugehörigen Werkzeugen.

HTML ist nicht so kompliziert zu verstehen wie Rust. HTML wird nicht in eine andere Form kompiliert, bevor es geparst wird (es wird interpretiert, nicht kompiliert). Und die [Element]-Syntax(/de/docs/Glossary/element) von HTML ist wahrscheinlich viel einfacher zu verstehen als eine "echte Programmiersprache" wie Rust, JavaScript oder Python.

Die Art und Weise, wie Browser HTML parsen, ist viel nachsichtiger als die, wie die meisten Programmiersprachen geparst werden, was sowohl gut als auch schlecht ist.

Aber zuerst, was meinen wir mit nachsichtig? Nun, im Allgemeinen gibt es, wenn Sie etwas im Code falsch machen, zwei Haupttypen von Fehlern, auf die Sie stoßen werden:

• Syntaxfehler: Dies sind Tippfehler in Ihrem Code, die dazu führen, dass das Programm nicht ausgeführt wird, wie der zuvor gezeigte Rust-Fehler. Diese sind normalerweise leicht zu beheben, solange Sie mit der Syntax der Sprache vertraut sind und wissen, was die Fehlermeldungen bedeuten.
• Logikfehler: Dies sind Fehler, bei denen die Syntax tatsächlich korrekt ist, der Code jedoch nicht das tut, was Sie beabsichtigt haben, was bedeutet, dass das Programm falsch läuft. Diese sind oft schwerer zu beheben als Syntaxfehler, da es keine Fehlermeldung gibt, die Sie zur Fehlerquelle führt.

HTML selbst leidet nicht unter Syntaxfehlern, da Browser es nachsichtig parsen, was bedeutet, dass die Seite trotzdem angezeigt wird, selbst wenn es Syntaxfehler im Quellcode gibt. Browser haben eingebaute Regeln, um zu bestimmen, wie inkorrekt geschriebene HTML-Auszeichnung (oft als ungültig oder schlecht geformt bezeichnet) interpretiert wird, und ändern es automatisch in eine gültige Auszeichnung.

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 stehen, tut es aber nicht — es steht danach.

Wenn Sie dieses HTML in einen Browser laden und dann das gerenderte DOM ansehen, werden Sie sehen, dass die Verschachtelung von dem 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 also sowohl gut als auch schlecht? Nun, in diesem Fall hat der Browser das beabsichtigte Ergebnis erzielt, aber wie Sie später sehen werden, ist das nicht immer der Fall. Sie bekommen immer irgendetwas zum Laufen, aber der Browser macht es nicht immer richtig, was Probleme verursachen kann. Es ist besser, von Anfang an korrekte Auszeichnung zu schreiben.

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

Alle modernen Browser haben eine Reihe von Entwickler-Tools (DevTools) eingebaut, die eine funktionale Auswahl zum Untersuchen der in den aktuellen Tab geladenen Webseite bieten. Diese können Ihnen zeigen, welche HTML im Dokument gerendert wird, welches CSS auf jeden DOM-Knoten angewendet wird, welches JavaScript im Dokument läuft und mehr. Sie ermöglichen Ihnen auch, den gerade laufenden Code zu bearbeiten und die Auswirkung live auf der Seite zu sehen.

Sie können die DevTools in jedem Browser auf ähnliche Weise öffnen — sehen Sie Wie man die DevTools im Browser öffnet um zu lernen, wie.

Für diesen Artikel ist die einzige relevante DevTools-Funktion der DOM-Inspektor, der das aktuell gerenderte HTML DOM anzeigt und Ihnen erlaubt, es zu bearbeiten. Sehen 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 — der erste Tab in den DevTools am Anfang der Reihe. In Firefox ist er als Inspector beschriftet, während er in Safari, Edge und Chrome als Elements bezeichnet wird. Dies sollte der standardmäßig ausgewählte Tab sein, wenn Sie die DevTools zum ersten Mal öffnen, aber wählen Sie ihn aus, wenn dies nicht der Fall ist.
3. Untersuchen Sie die im Tab gezeigte DOM-Baumstruktur und beachten Sie, wie Sie auf die kleinen Erweiterungspfeile am Anfang jedes DOM-Knotens klicken können, um diese zu erweitern und zu reduzieren und um ihre Nachkommensknoten zu enthüllen. Sie können auch die Aufwärts- und Abwärtspfeiltasten verwenden, um durch die Knoten nach oben und unten zu springen, sowie die rechte und linke Pfeiltaste, um die Knoten zu erweitern und zu reduzieren.
4. Versuchen Sie auch die Knoten zu überfahren (oder sie mit den Pfeiltasten auszuwählen) und beachten Sie, wie das aktuell überfahrene (oder ausgewählte) Element im Ansichtsfenster hervorgehoben wird.
5. Sie können auch das gerenderte DOM bearbeiten. Wir werden die Bearbeitungsfunktion in diesem Artikel nicht verwenden, aber nehmen Sie sich etwas Zeit, um nachzuschlagen, wie dies geht, wenn Sie neugierig sind.

In diesem Abschnitt untersuchen Sie etwas Code mit dem DOM-Inspektor und sehen, wie der Browser häufige Markup-Fehler verarbeitet.

1. Speichern Sie zunächst die folgende HTML-Dateiliste als debug-example.html an einem beliebigen Ort auf Ihrem lokalen Gerät. Dieses Demo-Beispiel ist absichtlich mit einigen eingebauten Fehlern geschrieben, die wir untersuchen 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 es anschließend in einem Browser. Sie werden etwa Folgendes sehen:

3. Dies sieht sofort nicht sehr gut aus; lassen Sie uns den Quellcode anschauen, um zu sehen, ob wir herausfinden können, warum (es sind nur die Inhaltsbereiche des Bodys 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 Absatz und Listenelement-Elemente haben keine Schließtags. Wenn Sie sich das obige Bild ansehen, scheint dies das Markup-Rendering nicht allzu stark beeinträchtigt zu haben, da es leicht ist, zu erkennen, wo ein Element enden und ein anderes beginnen sollte.
   • Das erste <strong>-Element hat keinen Schließtag. Das ist etwas problematischer, da man nicht leicht erkennen kann, wo das Element enden soll. Tatsächlich wurde der gesamte restliche Text in Fett gedruckt.
   • Dieser Abschnitt ist schlecht verschachtelt: <strong>strong <em>strong emphasized?</strong> what is this?</em>. Wegen des vorherigen Problems ist es nicht einfach zu erkennen, wie das interpretiert wurde.
   • Der href Attributwert besitzt kein schließendes Anführungszeichen. Dies scheint das größte Problem verursacht zu haben — der Link wurde überhaupt nicht gerendert.

5. Lassen Sie uns nun das gerenderte DOM untersuchen, im Gegensatz zum Quellcode. Öffnen Sie dazu den DOM-Inspektor Ihres Browsers. Sie sehen eine Darstellung des gerenderten Markups:

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

   • Die Absätze und Listenelemente wurden mit Schließtagen versehen.

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

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

     html

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

   • Der Link mit dem fehlenden Anführungszeichen wurde insgesamt 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>
     

Anhand des obigen Beispiels können Sie 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, die Zeilen zu durchsuchen und die Fehler zu finden, aber was ist mit einem riesigen, komplexen HTML-Dokument?

Das Werkzeug für diesen Job ist der Markup Validation Service (oder HTML-Validator), der von der W3C erstellt und gewartet wird (wie Sie im Web-Standards-Modell gelernt haben). Der Validator nimmt ein HTML-Dokument als Eingabe, durchläuft es und erstellt einen Bericht, um Ihnen mitzuteilen, was mit Ihrem HTML nicht in Ordnung ist.

Um das zu validierende HTML anzugeben, können Sie eine Webadresse angeben, eine HTML-Datei hochladen oder direkt HTML-Code eingeben.

In dieser Aufgabe werden wir Sie dazu bringen, den HTML-Validator auszuprobieren. Sie werden unser Beispieldokument validieren und sehen, welche Ergebnisse zurückgegeben werden. Dieses Beispiel enthält dasselbe HTML, das Sie zuvor mit dem DOM-Inspektor studiert haben.

1. Laden Sie zuerst den Markup Validation Service in einem neuen Browser-Tab, falls er noch nicht geöffnet ist.
2. Wechseln Sie zur Registerkarte Direkteingabe validieren.
3. Kopieren Sie den gesamten Code des Beispieldokuments (nicht nur den Body) und fügen Sie ihn in das große Textfeld ein, das im Markup Validation Service angezeigt wird.
4. Drücken Sie die Check-Taste.

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

Die Fehlermeldungen sind in der Regel hilfreich, aber manchmal sind sie nicht ganz leicht zu verstehen. Mit ein bisschen Übung können Sie herausfinden, wie Sie diese interpretieren, um Ihren Code zu beheben. Gehen wir die Fehlermeldungen durch und sehen, was sie bedeuten. Sie sehen, dass jede Nachricht mit einer Zeilen- und Spaltennummer geliefert wird, die Ihnen hilft, den Fehler leicht zu lokalisieren.

• "Ende-Tag li impliziert, aber es gab offene Elemente" (2 Instanzen): Diese Meldungen weisen darauf hin, dass ein Element geöffnet ist, das geschlossen werden sollte. Das Schlusstag ist impliziert, aber eigentlich nicht vorhanden. Die Zeilen-/Spaltendaten zeigen auf die erste Zeile nach der Zeile, in der das Schlusstag wirklich sein sollte, aber dies ist ein guter Hinweis, um zu sehen, was falsch ist.

• "Ungeschlossenes Element strong": Dies ist einfacher zu verstehen — ein <strong>-Element ist ungeschlossen und die Zeilen-/Spalteninformationen zeigen genau darauf, wo es sich befindet.

• "Endtag strong verletzt Verschachtelungsregeln": Dies weist auf die falsch verschachtelten Elemente hin und die Zeilen-/Spalteninformationen zeigen, wo sie sich befinden.

• "Dateiende erreicht, als ein Attributwert geöffnet war. Tag ignoriert": Diese Nachricht ist eher kryptisch; sie bezieht sich darauf, dass es einen nicht richtig geformten Attributwert gibt, möglicherweise nahe dem Dateiende, weil das Dateiende innerhalb des Attributwertes zu liegen scheint. Die Tatsache, dass der Browser den Link nicht rendert, sollte uns einen guten Hinweis darauf geben, welches Element schuld ist.

• "Dateiende gesehen und es gab offene Elemente": Das ist etwas zweideutig, aber im Grunde bezieht es sich darauf, dass es offene Elemente gibt, die richtig geschlossen werden müssen. Die Zeilennummern zeigen auf die letzten Zeilen der Datei, und diese Fehlermeldung wird mit einer Codezeile geliefert, 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, dem ein schließendes Anführungszeichen fehlt, kann zu einem offenen Element führen, da der Rest des Dokuments als Inhalt des Attributs interpretiert wird.

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

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 korrigieren und dann Ihr HTML nach jedem Satz von Korrekturen erneut zu validieren, um zu sehen, welche Fehler noch übrig sind. Manchmal beseitigt die Behebung eines früheren Fehlers auch andere Fehlermeldungen – mehrere Fehler können oft durch ein einziges Problem verursacht werden, in einem Dominoeffekt.

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

Damit haben wir eine Einführung in das Debugging von HTML abgeschlossen, die Ihnen einige nützliche Fähigkeiten bietet, auf die Sie beim Debuggen von HTML, aber auch von CSS und JavaScript-Code im späteren Verlauf des Kurses zurückgreifen können. Dies markiert auch das Ende des Moduls Content-Strukturierung mit HTML.

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