Debugging von HTML

Beim Schreiben von Code ist in der Regel alles in Ordnung, bis zu dem 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 Fehler, der beim Versuch aufgetreten ist, ein einfaches Programm in der Rust Sprache zu kompilieren.

Hier ist die Fehlermeldung relativ leicht zu verstehen — "nicht abgeschlossenes doppeltes Anführungszeichen in Zeichenkette". Wenn Sie sich den Code ansehen, können Sie wahrscheinlich sehen, wie println!(Hello, world!"); logischerweise ein doppeltes Anführungszeichen fehlt. Allerdings können Fehlermeldungen schnell komplizierter und weniger verständlich werden, wenn Programme größer werden, und selbst einfache Fälle können für jemanden, der nichts über Rust weiß, ein wenig abschreckend wirken.

Debugging muss jedoch nicht beängstigend sein — der Schlüssel zum sicheren Umgang mit dem Schreiben und Debuggen in jeder Programmiersprache oder jedem Code ist die Vertrautheit mit sowohl der Sprache als auch den Werkzeugen.

HTML zu verstehen ist nicht so kompliziert wie Rust. HTML wird nicht in eine andere Form kompiliert, bevor es vom Browser geparst und das Ergebnis angezeigt wird (es wird interpretiert, nicht kompiliert). Und die Syntax von HTML-Elementen ist vermutlich viel einfacher zu verstehen als eine "echte Programmiersprache" wie Rust, JavaScript oder Python. Die Art und Weise, wie Browser HTML parsen, ist wesentlich zulässiger als die Ausführung von Programmiersprachen, was sowohl gut als auch schlecht ist.

Was meinen wir mit zulässig? Nun, im Allgemeinen gibt es zwei Haupttypen von Fehlern, auf die Sie stoßen können, wenn Sie etwas falsch im Code machen:

• Syntaxfehler: Das sind Rechtschreib- oder Interpunktionsfehler in Ihrem Code, die dazu führen, dass das Programm nicht ausgeführt wird, wie der oben gezeigte Rust-Fehler. Diese sind in der Regel einfach zu beheben, solange Sie die Syntax der Sprache kennen und wissen, was die Fehlermeldungen bedeuten.
• Logikfehler: Das sind Fehler, bei denen die Syntax tatsächlich korrekt ist, der Code jedoch nicht das ist, was Sie beabsichtigt haben, wodurch das Programm falsch ausgeführt wird. Diese sind oft schwieriger zu beheben als Syntaxfehler, da keine Fehlermeldung vorhanden ist, um Sie auf die Ursache des Fehlers hinzuweisen.

HTML selbst leidet nicht unter Syntaxfehlern, da Browser es zulässig parsen, was bedeutet, dass die Seite trotzdem angezeigt wird, auch wenn Syntaxfehler vorhanden sind. Browser haben eingebaute Regeln, die vorschreiben, wie falsch geschriebenes Markup interpretiert werden soll, sodass Sie etwas Laufendes erhalten, auch wenn es nicht das ist, was Sie erwartet haben. Das kann natürlich immer noch ein Problem sein!

Es ist Zeit, die zulässige Natur von HTML-Code zu studieren.

1. Laden Sie zuerst unser Debug-Example-Demo herunter und speichern Sie es lokal. Diese Demo enthält absichtlich einige eingebaute Fehler, die wir erkunden werden (das HTML-Markup ist schlecht geformt, im Gegensatz zu gut geformt).

2. Öffnen Sie es anschließend in einem Browser. Sie werden etwas Ähnliches sehen:

3. Dies sieht sofort nicht gut aus; sehen wir uns den Quellcode an, um herauszufinden, warum (nur der Body-Inhalt 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 Betrachten des obigen Bildes scheint dies das Markup-Rendering nicht allzu sehr beeinträchtigt zu haben, da sich leicht erkennen lässt, wo ein Element enden und ein anderes beginnen sollte.
   • Das erste <strong> Element hat keinen Schlusstag. Dies ist etwas problematischer, da es nicht leicht zu erkennen ist, wo das Element enden soll. Tatsächlich ist der gesamte restliche Text stark hervorgehoben.
   • Dieser Abschnitt ist schlecht verschachtelt: <strong>strong <em>strong emphasized?</strong> what is this?</em>. Es ist nicht leicht zu erkennen, wie dies aufgrund des vorherigen Problems interpretiert wurde.
   • Der href Attributwert fehlt ein abschließendes doppeltes Anführungszeichen. Dies scheint das größte Problem verursacht zu haben — der Link wurde überhaupt nicht gerendert.

5. Schauen wir uns nun das Markup an, das der Browser gerendert hat, im Gegensatz zu dem Markup im Quellcode. Um dies zu tun, können wir die Entwicklertools des Browsers verwenden. Wenn Sie nicht mit der Verwendung der Entwicklertools Ihres Browsers vertraut sind, nehmen Sie sich ein paar Minuten, um Entdecken Sie Entwicklertools Ihres Browsers zu überprüfen.

6. Im DOM-Inspektor können Sie sehen, wie das gerenderte Markup aussieht:

7. Mit dem DOM-Inspektor können wir unseren Code im Detail erkunden, um zu sehen, wie der Browser versucht hat, unsere HTML-Fehler zu beheben (wir haben die Überprüfung in Firefox durchgeführt, andere moderne Browser sollten das gleiche Ergebnis liefern):

   • Die Absätze und Listenelemente wurden mit Schlusstags versehen.

   • Es ist nicht klar, wo das erste <strong> Element geschlossen werden sollte, also hat der Browser jeden separaten Textblock mit seinem eigenen strong-Tag umwickelt, 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 doppelten Anführungszeichen wurde vollständig gelöscht. Das letzte Listenelement sieht folgendermaßen aus:

     html

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

Wie Sie aus dem obigen Beispiel sehen können, ist es wirklich wichtig, sicherzustellen, 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 mit einem großen, komplexen HTML-Dokument?

Die beste Strategie besteht darin, Ihre HTML-Seite zunächst durch den Markup Validation Service zu laufen — erstellt und gepflegt vom W3C, der Organisation, die sich um die Spezifikationen kümmert, die HTML, CSS und andere Webtechnologien definieren. Diese Webseite nimmt ein HTML-Dokument als Eingabe, geht es durch und gibt Ihnen einen Bericht, der Ihnen mitteilt, was an Ihrem HTML falsch ist.

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

Versuchen wir dies mit unserem Beispieldokument.

1. Laden Sie zuerst den Markup Validation Service in einem Browser-Tab, falls er noch nicht geöffnet ist.
2. Wechseln Sie zum Tab Validate by Direct Input.
3. Kopieren Sie den gesamten Code des Beispieldokuments (nicht nur den Body) und fügen Sie ihn in den großen Textbereich des Markup Validation Service ein.
4. Drücken Sie die Check Schaltfläche.

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

Die Fehlermeldungen sind normalerweise hilfreich, aber manchmal nicht so hilfreich; mit ein wenig Übung können Sie lernen, sie zu interpretieren, um Ihren Code zu reparieren. Lassen Sie uns die Fehlermeldungen durchgehen und sehen, was sie bedeuten. Sie werden feststellen, dass jede Meldung mit einer Zeilen- und Spaltennummer versehen ist, um Ihnen das Auffinden des Fehlers zu erleichtern.

• "End tag li implied, but there were open elements" (2 Instanzen): Diese Meldungen geben an, dass ein Element geöffnet ist, das geschlossen werden sollte. Das Schlusstag wird impliziert, ist aber nicht tatsächlich vorhanden. Die Zeilen/Spalten-Informationen weisen auf die erste Zeile nach der Zeile, in der das Schlusstag tatsächlich stehen sollte, hin, aber dies ist ein ausreichend guter Hinweis, um zu sehen, was falsch ist.

• "Unclosed element strong": Das ist wirklich einfach zu verstehen — ein <strong> Element ist nicht geschlossen, und die Zeilen/Spalten-Informationen weisen direkt darauf hin, wo es sich befindet.

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

• "End of file reached when inside an attribute value. Ignoring tag": Das ist ziemlich kryptisch; es bezieht sich darauf, dass ein Attributwert irgendwo nicht richtig geformt ist, möglicherweise nahe dem Ende der Datei, weil das Ende der Datei innerhalb des Attributwerts erscheint. Die Tatsache, dass der Browser den Link nicht rendert, sollte uns einen guten Hinweis darauf geben, welches Element schuld ist.

• "End of file seen and there were open elements": Das ist etwas mehrdeutig, bezieht sich letztendlich aber darauf, dass es offene Elemente gibt, die richtig geschlossen werden müssen. Die Zeilennummern weisen auf die letzten paar Zeilen der Datei hin, und diese Fehlermeldung enthält eine Codezeile, 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 dazu führen, dass ein Element offen bleibt, da der Rest des Dokuments als Inhalt des Attributs interpretiert wird.

• "Unclosed element ul": Das ist nicht sehr hilfreich, da das <ul> Element korrekt geschlossen ist. Diese Fehlermeldung erscheint, weil das <a> Element nicht geschlossen ist, aufgrund des fehlenden abschließenden Anführungszeichens.

Wenn Sie nicht herausfinden können, was jede Fehlermeldung bedeutet, machen Sie sich keine Sorgen darüber — eine gute Idee ist, einige Fehler gleichzeitig zu beheben. Versuchen Sie dann, Ihr HTML erneut zu validieren, um zu sehen, welche Fehler noch vorhanden sind. Manchmal kann das Beheben eines früheren Fehlers auch andere Fehlermeldungen beseitigen — mehrere Fehler können oft durch ein einziges Problem verursacht werden, in einem Dominoeffekt.

Sie werden wissen, wann alle Fehler behoben sind, wenn Sie das folgende Banner in Ihrem Output sehen:

TODO

Das war also eine Einführung in das Debuggen von HTML, die Ihnen einige nützliche Fähigkeiten vermitteln sollte, auf die Sie zählen können, wenn Sie später in Ihrer Karriere CSS, JavaScript und andere Codearten debuggen. Dies markiert auch das Ende der Einführung in das HTML-Modul Lernartikel — jetzt können Sie sich mit unseren Bewertungen selbst testen: Die erste ist unten verlinkt.

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