Diese Übersetzung ist in Arbeit.

HTML-Code zu schreiben ist die eine Sache. Fehler die sich beim Entwickeln einschleichen zu finden und zu beheben die andere. In diesem Artikel stellen wir einige Werkzeuge vor, mit welchen man Fehler in HTML finden und beheben kann.

Vorwissen:

Grundkenntnisse in HTML, wie sie in den Artikeln Lernen Sie HTML kennen, Einfache Textformattierung mit HTML und Erstellen von Links abgedeckt werden.

Ziel:

Die Grundlagen zur Fehlersuche in HTML, mit Hilfe von entsprechenden Werkzeugen, kennen lernen.

Keine Angst vor der Fehlersuche

Wenn Computercode geschrieben wird, dann ist meistens alles in Ordnung, bis zu dem Moment in dem ein Fehler auftritt - es wurde etwas falsch gemacht, deswegen funktioniert der Code nicht - entweder überhaupt nicht, oder nicht so wie es vorgesehen war. Als Beispiel zeigen wir einen Fehlerbericht, der beim compilieren eines einfachen Programmes in der Programmiersprache Rust, ausgegeben wurde.

A console window showing the result of trying to compile a rust program with a missing quote around a string in a print statement. The error message reported is error: unterminated double quote string. "Error" ist Englisch und bedeutet Fehler. In diesem Beispiel gibt die Fehlerwarnung aus "unterminated double quote string", was bedeutet, dass ein doppeltes Anführungszeichen fehlt. Wenn man sich println!(Hello, world!"); anschaut, dann kann man sehen, das dort doppelte Anführungszeichen fehlen. Dieser Fehler ist dank der Fehlermeldung einfach zu finden und zu beheben. Fehlermeldungen können aber um einiges komplizierter sein, als in diesem Beispiel. Vor allem bei größeren Programmen, mit mehr Code, sind Fehler unvermeidlich und für jemanden, der eine Programmiersprache nicht kennt, wird es fast unmöglich, diese zu finden.

Begriffserklärungen Fehlerbehebung

Im Computerbereich wurden viele Begriffe aus dem Englischen übernommen, so auch in diesem Bereich. So wird Fehlerbehebung auch im deutschen Sprachgebrauch Debugging genannt. Der Fehler im Code wird im Englischen als Bug bezeichnet, was soviel wie Ungeziefer bedeutet. Das Debugging ist dann das Entfernen des Ungeziefers Als Debugger wird ein Programm bezeichnet, welches zur Fehlersuche und -behebung genutzt wird.

Die Fehlerbehebung, das debuggen also, muss niemandem Angst machen, auch wenn es viel Arbeit ist. Der Schlüssel zum Schreiben und Debuggen von Programmiercode ist Vertrautheit mit der entsprechenden Programmiersprache und den Wekrzeugen zur Fehlerbehebung.

HTML und Debugging

Die Syntax von HTML ist um einiges einfacher als in einer "echten" Programmiersprache, wie Rust, Javascript oder Python. Auch wird HTML nicht erst compiliert, sondern direkt vom Browser interpretiert. Browser sind beim rendern von HTML sehr permissiv. Fehler bewirken normalerweise nicht, wie bei anderen Programmiersprachen üblich, das ein Dokument gar nicht dargestellt wird, sondern der Browser rendert das HTML-Dokument trotzdem, was sowohl gut, als auch schlecht sein kann.

Permissiver Code

Was bedeutet permissiv? Wenn man in Programmiersprachen etwas falsch macht, dann gibt es normalereise zwei Sorten von Fehlern, denen man begegnet:

  • Syntaxfehler: Dies sind Schreibfehler im Code, welche bewirken, dass das Programm nicht läuft, wie das obige Beispiel in Rust. Syntaxfehler sind leicht zu finden und zu beheben, wenn man mit der entsprechenden Programmierprache vertraut ist und man weiß, wie man Fehlermeldungen interpretiert.
  • Logische Fehler: Diese Fehler treten auf, wenn die Syntax korrekt ist, der Code aber nicht das tut, was er tun soll. Das Programm läuft, aber nicht so wie erwartet. Logische Fehler sind schwieriger zu beheben, weil es keine Fehlermeldung gibt, die einen zu der Fehlerquelle führt.

HTML ignoriert Syntaxfehler, Browser rendern permissiv, die Seite wird angezeigt, obwohl Syntaxfehler im Code sind. Browser haben Regeln eingebaut, welche falsch geschriebenen HTML-Code trotzdem interpretieren, allerdings meist nicht so, wie es vorgesehen war. Die Fehler müssen trotzdem behoben werden.

Hinweis: Warum wird HTML permissiv gerendert? Weil bei der Entwicklung des World Wide Web befunden wurde, dass es wichtiger ist, dass Leute ihre Inhalte publizieren können. Wichtiger als ein paar Syntaxfehler im Code, die eine Veröffentlichung verhindern würden. Das Internet wäre vermutlich nicht so populär, wenn die Regeln der Sprache strenger gewesen wären.

Aktives Lernen: Permissiven Code untersuchen

Es ist Zeit sich anzuschauen, wie permissiv HTML Code gerendert wird.

  1. Laden Sie bitte die folgende Datei herunter und speichern sie diese lokal: debug-example demo In diesem Demo-Code sind absichtlich einige Fehler verbaut. Der HTML-Code ist schlecht geschrieben.
  2. Öffnen Sie diese Datei in einem Browser. Sie sollten folgendes sehen: A simple HTML document with a title of HTML debugging examples, and some information about common HTML errors, such as unclosed elements, badly nested elements, and unclosed attributes.
  3. Das sieht gleich etwas merkwürdig aus. Schauen sie sich nun den Quellcode der Datei an:
    <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 emphasised?</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 erläutern:
    • Die Absatz und Listenpunkt Elemente haben keine schließenden Tags. Auf dem Bild oben sehen wir, das dies kaum Auswikrungen hat, da es für den Browser einfach ist, trotzdem zu erkennen, wo das Ende dieser Elemente sein sollte.
    • Das erste <strong> Element hat kein schließendes Tag. Der Browser kann nicht erraten, wo das Element enden soll, deswegen ist der ganze Rest von dem Text stark hervorgehoben.
    • Diese Sektion des Textes wurden die Elemente schlecht verschachtelt. <strong>strong <em>strong emphasised?</strong> what is this?</em>. Wegen dem vorhergehenden Problem, kann man nicht sagen, wie dies vom Browser interpretiert wird.
    • Bei dem href-Attributwert wurde ein schließendes, doppeltes Anführungszeichen vergessen. Dies scheint das größte Problem zu verursachen, der Link ist gar nicht erst gerendert worden.
  5. Lassen Sie uns den Code anschauen den der Browser zum rendern benutzt hat, im Gegensatz zu dem geschriebenen Quellcode. Dafür benutzen wir die Web Developer Tools, die in jedem modernen Browser enthalten sind (nicht aber in der mobilen Version der Browser). Wenn Sie nicht wissen, was Web Developer Tools sind, dann nehmen Sie sich einige Minuten Zeit, um diesen Artikel zu lesen: Entdecken Sie die Web Developer Tools
  6. In dem DOM-Inspektor können Sie sehen, wie der gerenderte Code aussieht: The HTML inspector in Firefox, with our example's paragraph highlighted, showing the text "What causes errors in HTML?" Here you can see that the paragraph element has been closed by the browser.
  7. Mit Hilfe des DOM-Inspektors können wir den Code den der Browser versucht hat zu beheben sehen und wie dieser versucht die HTML Fehler zu beheben. (Wir habe hier Firefox benutzt, um den Code anzuschauen; andere moderne Browser sollten zu dem selben Resultat kommen.):
    • Den Absätzen und den Listenpunkten wurden schließende Tags hinzugefügt.
    • Es ist nicht klar, wo das erste <strong>-Element enden soll, deswegen hat der Browser jeden separaten Block mit einem eigenen <strong>-Tag versehen, bis zum Ende des Dokumentes!
    • Die falsch verschachtelten Elemente wurden vom Browser wie folgt gelöst:
      <strong>strong
        <em>strong emphasised?</em>
      </strong>
      <em> what is this?</em>
    • Der Link mit den fehlenden, doppelten Anführungszeichen wurde komplett gelöscht. Das letzte Listenelement sieht so aus:
      <li>
        <strong>Unclosed attributes: Another common source of HTML problems.
        Let's look at an example: </strong>
      </li>

HTML Validation

Es ist auf jeden Fall besser, die korrekte Syntax für HTML zu verwenden, um ungewollte Ergebnisse zu vermeiden. Aber wie? Bei einem kleinen Dokument, wie dem obigen, ist es einfach, dieses Zeile für Zeile durchzugehen, um die Fehler zu finden. Aber was bei einem sehr großen HTML-Dokument tun?

Die beste Strategie ist es, das HTML-Dokument von dem Markup Validation Service überprüfen zu lassen. Dieses Tool wird von der W3C bereitgestellt, also von der Organisation, welche auch die Spezifikationen von HTML, CSS und anderen Internettechnologien erstellt. Dieser Webseite gibt man ein HTML-Dokument an, diese untersucht das Dokument auf Fehler und gibt einen detailierten Fehlerbericht zurück.

The HTML validator homepage

To specify the HTML to validate, you can give it a web address, upload an HTML file, or directly input some HTML code.

Active learning: Validating an HTML document

Let's try this with our sample document.

  1. First, load up the Markup Validation Service in one browser tab, if it isn't already.
  2. Switch to the Validate by Direct Input tab.
  3. Copy all the sample document's code (not just the body) and paste it into the large text area shown in the Markup Validation Service.
  4. Press the Check button.

This should give you a list of errors and other information.

A list of of HTML validation results from the W3C markup validation service

Interpreting the error messages

The error messages are usually helpful, but sometimes they are not so helpful; with a bit of practice you can work out how to interpret these to fix your code. Let's go through the error messages and what they mean. You'll see that each message comes with a line and column number to help you to locate the error easily.

  • "End tag li implied, but there were open elements" (2 instances): These messages indicate that an element is open that should be closed. The ending tag is implied, but not actually there. The line/column information points to the first line after the line where the closing tag should really be, but this is a good enough clue to see what is wrong.
  • "Unclosed element strong": This is really easy to understand — a <strong> element is unclosed, and the line/column information points right to where it is.
  • "End tag strong violates nesting rules": This points out the incorrectly nested elements, and the line/column information points out where it is.
  • "End of file reached when inside an attribute value. Ignoring tag": This one is rather cryptic; it refers to the fact that there is an attribute value not properly formed somewhere, possibly near the end of the file because the end of the file appears inside the attribute value. The fact that the browser doesn't render the link should give us a good clue as to what element is at fault.
  • "End of file seen and there were open elements": This is a bit ambiguous, but basically refers to the fact there are open elements that need to be properly closed. The lines numbers point to the last few lines of the file, and this error message comes with a line of code that points out an example of an open element:
    example: <a href="https://www.mozilla.org/>link to Mozilla homepage</a> ↩ </ul>↩ </body>↩</html>

    Note: An attribute missing a closing quote can result in an open element because the rest of the document is interpreted as the attribute's content.

  • "Unclosed element ul": This is not very helpful, as the <ul> element is closed correctly. This error comes up because the <a> element is not closed, due to the missing closing quote mark.

If you can't work out what every error message means, don't worry about it — a good idea is to try fixing a few errors at a time. Then try revalidating your HTML to show what errors are left. Sometimes fixing an earlier error will also get rid of other error messages — several errors can often be caused by a single problem, in a domino effect.

You will know when all your errors are fixed when you see the following banner in your output:

Banner that reads "The document validates according to the specified schema(s) and to additional constraints checked by the validator."

Summary

So there we have it, an introduction to debugging HTML, which should give you some useful skills to count on when you start to debug CSS, JavaScript, and other types of code later on in your career. This also marks the end of the Introduction to HTML module learning articles — now you can go on to testing yourself with our assessments: the first one is linked below.

 

In this module

 

Schlagwörter des Dokuments und Mitwirkende

Mitwirkende an dieser Seite: Shidigital
Zuletzt aktualisiert von: Shidigital,