Um diesen Abschnitt umfassend verstehen zu können, benötigen Sie Kenntnisse über die Syntax und das Vokabular von XHTML und sollten wissen, wie HTML und XHTML aus SGML und XML entstanden sind. Zum Teil greife ich Inhalten weiterer Teile dieser Einführung vor, allerdings denke ich, dass ein Abschnitt über Validatoren in diesem Kapitel am besten aufgehoben ist – schließlich gehören Validatoren zu den wichtigsten Hilfsmitteln eines Webautors überhaupt. Anfänger sollten diesen Abschnitt zunächst überspringen und ihn sich für einen späteren Zeitpunkt vormerken.

Natürliche und formale Sprachen

Damit sich zwei Menschen miteinander verständigen können, benötigen sie eine gemeinsame (natürliche) Sprache. Zum einen müssen sich beide ein gemeinsames Vokabular teilen, also über eine ausreichend große Menge an Wörtern verfügen und sich über deren Bedeutung und Funktion einig sein. Zum anderen müssen sie zumindest in groben Zügen dieselben Regeln dazu befolgen, wie aus einzelnen Wörtern Bedeutungsgruppen und daraus wiederum Sätze geformt werden. Im Idealfall lassen sich dann Sätze formulieren, deren Bedeutung eindeutig und beiden Beteiligten klar ist.

So einfach ist dies jedoch nicht. Jeder weiß aus der alltäglichen Kommunikation mit Menschen in seiner Umgebung, dass sich die Bedeutung von Ausdrücken oft nur aus dem Zusammenhang ergibt. Wesentliche Bestandteile einer natürlichen Sprache sind nicht nur Vokabular und Grammatik, sondern auch Melodie und Rhythmus, Mimik und Gestik, Ironie und Sarkasmus, Emotion und Beziehungsdefinitionen. Hinzu kommt, dass viele Äußerungen in natürlicher Sprache nicht nur in ihrer Bedeutung (Semantik), sondern auch in ihrer grammatikalischen Struktur (Syntax) mehrdeutig sind. Der Ausdruck »die Auswahl des Mannes mit dem Zeigestock« veranschaulicht dieses Problem. Der Mann könnte ausgewählt worden sein oder selbst eine Auswahl getroffen haben; es kann sowohl »die Auswahl mit dem Zeigestock« gemeint sein als auch »der Mann mit dem Zeigestock«.

Natürliche Sprachen sind nicht vollständig durch ein festgelegtes Regelwerk, sondern durch ihren Gebrauch definiert und unterliegen ständigem Wandel. Es kann daher nicht immer zweifelsfrei bestimmt werden, ob eine Äußerung oder ein Satz einer bestimmten natürlichen Sprache zuzuordnen und in diesem Zusammenhang »richtig« oder »falsch« ist. Daher sind natürliche Sprachen für die Kommunikation zwischen Menschen und Computern oder Computerprogrammen untereinander nicht geeignet. Anders als wir Menschen kann ein Computer Mehrdeutigkeiten nicht auflösen und ist auch nicht in der Lage, zwischen den Zeilen zu lesen und die Bedeutung eines Ausdrucks aus dem Kontext heraus zu interpretieren. Besser eignen sich formale Sprachen, deren Semantik und syntaktische Regeln anders als bei natürlichen Sprachen eindeutig sind.

HTML als SGML-Dokumenttyp und XHTML als XML-Dokumenttyp sind formale Sprachen. Die Grammatik wird durch die syntaktischen Regeln gebildet, die für SGML beziehungsweise XML definiert sind, sowie durch die Elementstrukturen, die die jeweilige Dokumenttyp-Definition (DTD) oder das Schema vorgibt – also welche Elemente auf welche Weise ineinander verschachtelt werden dürfen, welche Attribute sie haben dürfen oder müssen und welche Werte diese annehmen können. Das folgende Beispiel ist aus zwei Gründen falsch: Es verstößt gegen die Syntax von XHTML, weil ein Element p keine anderen Blockelemente enthalten darf, und hält sich nicht an das vorgegebene Vokabular, da es einen Elementtyp et verwendet, der nicht in XHTML enthalten ist:

<p>Das folgende Beispiel ist aus zwei Gründen falsch: Es

  <ul>
    <li>verstößt gegen die Syntax von XHTML, weil ein
      Element <et>p</et> keine anderen Blockelemente
      enthalten darf, und</li>
    <li>hält sich nicht an das vorgegebene Vokabular,
      da es einen Elementtyp <et>et</et> verwendet,
      der nicht in XHTML enthalten ist.</li>
  </ul>
</p>

Ein Computer, genauer gesagt ein Validator, kann HTML- und XHTML-Dokumente mithilfe eines Parsers überprüfen und Fehler so eindeutig erkennen.

Zum Seitenanfang

Syntaktische Fehler und proprietäre Erweiterungen

Viele sogenannte WYSIWYG-Editoren produzieren noch heute teilweise unsauberes oder gar fehlerhaftes (X)HTML. Aber auch Webautoren, die ihre Dokumente per Hand schreiben, sind vor Fehlern nicht gefeit; wie schnell vergisst man, ein schließendes Tag zu setzen, oder fügt einen URL ein und übersieht ein nicht maskiertes Ampersand (&). Derartige Fehler fallen bei mit dem MIME-Typ text/html ausgelieferten Dokumenten nicht auf, zumindest nicht auf den ersten Blick; es sei denn, man bemerkt fehlende oder falsch angezeigte Inhalte in der Darstellung. Dennoch bringen sie Probleme mit sich.

Sind Dokumente fehlerhaft geschrieben, muss der Browser die falschen Stellen interpretieren und sich für eine mögliche Darstellung entscheiden. Das bläht Webseiten auf und macht ihre Verarbeitung langsam. Darüber hinaus ist Fehlerbehandlung nicht genormt. Wer syntaktisch falsches (X)HTML schreibt, kann sich nicht darauf verlassen, dass aktuelle und zukünftige Browser die Dokumente richtig verarbeiten können und morgen noch genau so darstellen wie heute. Werden XHTML-Dokumente mit dem empfohlenen MIME-Typ application/xhtml+xml oder einem anderen XML-MIME-Typ ausgeliefert, zumindest an Browser wie Mozilla oder Firefox, die damit etwas anfangen können, wird die Verarbeitung des Dokuments sofort abgebrochen und eine Fehlermeldung angezeigt (siehe Abbildung 3.29) – die Informationen, die dargestellt werden sollten, sind somit nicht mehr zugänglich. Zudem erhalten potenzielle Besucher oder Kunden natürlich auch einen denkbar schlechten Eindruck von der fachlichen Qualifikation des jeweiligen Webautors.

Abb. 3.4: Firefox zeigt Verstöße gegen die Wohlgeformtheit eines XHTML-Dokuments gnadenlos an

Bei Verstößen gegen das Vokabular der verwendeten Sprachversion handelt es sich oft um Elemente oder Attribute, die nur in der Transitional-DTD enthalten sind, aber in einem strikten Dokument verwendet werden, oder um proprietäre Erweiterungen, die in keiner (X)HTML-DTD enthalten, also nicht genormt sind. Letzteres sind in den meisten Fällen Erweiterungen einzelner Browserentwickler, die oft auch nur in Browsern dieser Hersteller interpretiert werden. Vom Gebrauch solcher Erweiterungen ist abzuraten, da es sehr wahrscheinlich ist, dass sie in späteren Generationen des Browsers, in anderen Browsern oder auf anderen Plattformen nicht dargestellt werden oder zumindest anders als gewünscht, was viel schlimmer ist. Darüber hinaus können Werkzeuge wie Tidy (siehe Kapitel 3.4.1) Dokumente, die unbekannte Erweiterungen enthalten, nicht bearbeiten, da sie nicht wissen, wie sie mit diesen Erweiterungen umzugehen haben. Beispielsweise bleibt bei unbekannten Elementen innerhalb von XHTML-Dokumenten die Frage offen, ob das End-Tag erforderlich (wie bei a), optional (p) oder verboten (img) ist.

Zum Seitenanfang

Gültigkeit und Wohlgeformtheit

Ein Dokument ist gültig (valide), wenn es erfolgreich gegen eine zugrunde liegende Grammatik (DTD, Schema etc.) geprüft werden kann. Es dürfen also nur die Elemente, Attribute und Attributwerte auf die Art und Weise verwendet (und verschachtelt) werden, wie es für die gewählte Sprachversion definiert ist. Nur ein vollständig fehlerbereinigtes und korrekt geschriebenes Dokument verdient das Attribut gültig.

Die XML-Spezifikation definiert den Begriff »gültig« nur für XML-Dokumente, und genau genommen ist ein XML-Dokument nur dann ein solches, wenn es wohlgeformt ist. XHTML-Dokumente sind XML-Dokumente bestimmter Ausprägung, folglich ist Wohlgeformtheit ein notwendiges Kriterium, um XHTML-Dokumente auf Gültigkeit gegen eine bestimmte Dokumenttyp-Definition prüfen zu können. Diese Voraussetzung gibt es für HTML als SGML-Dokumenttyp nicht, denn SGML kennt das Konzept der Wohlgeformtheit nicht. Jedoch wird seit Aufkommen von X(HT)ML auch ein HTML-Dokument hin und wieder informell als »quasi-wohlgeformt« bezeichnet, wenn es den oben angegebenen, sofern in HTML möglichen, Regeln genügt.

Zum Seitenanfang

W3C Markup Validation Service

Um zu überprüfen, ob ein Dokument gültig ist, verwenden Webautoren einen für diesen Zweck programmierten Validator. Davon gibt es mittlerweile eine ganze Reihe auf dem Markt und frei für jeden verfügbar im Web. Der W3C Markup Validation Service ist der bekannteste. Er beschreibt sich selbst als freien Service, über den Webautoren Dokumente wie HTML- und XHTML-Dokumente bezüglich ihrer Konformität zu den W3C-Empfehlungen und anderen Standards überprüfen können. Aber auch der Validator der Web Design Group ist sehr populär. Nebenbei bemerkt, bietet dieser über die Funktion Validate entire site die Möglichkeit, bis zu 100 Dokumente einer Website in einem Schritt zu überprüfen.

Abb. 3.5: Der W3C Markup Validation Service

Typische Fehlermeldungen und ihre Bedeutung

Es gibt nicht viel, was Sie bei der Erstellung von (X)HTML-Dokumenten falsch machen können. Natürlich ist die Arbeit eines Webautors fehleranfällig, aber es handelt sich fast immer um dieselben Arten von Fehlern. Deswegen werden Sie, wenn Sie eine Weile mit dem W3C-Validator gearbeitet haben, das Gefühl haben, stets die gleichen Fehlermeldungen und Warnungen zu lesen. Zu den am häufigsten vorkommenden Fehlern gehören die folgenden:

No DOCTYPE Declaration Found!

Das Dokument enthält keine Dokumenttyp-Deklaration (siehe Kapitel 4.2.2), oder sie ist nicht korrekt.

No Character Encoding Found!

Das Dokument wird ohne Informationen zur Kodierung ausgeliefert. Überprüfen Sie Ihre Webservereinstellungen. Falls Sie lokal testen oder ein Dokument hochgeladen haben, müssen Sie die Kodierungsinformation per meta-Element angeben (siehe Kapitel 4.5).

Document type does not allow element "p" here; assuming missing "li" start-tag.

Ein Element p steht im Quelltext an einer Stelle, an die es nicht gehört. Der Validator weist Sie darauf hin, dass offenbar ein Element <li> fehlt.

End tag for element "p" which is not open.

Im Quelltext steht ein </p>, für das es kein öffnendes <p> gibt. Vielleicht ist der Grund dafür in einer fehlerhaften Elementverschachtelung zu suchen (also beispielsweise <p><strong>Es ist ein Fehler aufgetreten!</p></strong>).

End tag for "div" omitted, but OMITTAG NO was specified.

Im Quelltext steht ein <div>, für das es kein schließendes </div> gibt. Auch hier könnten Sie Elemente falsch verschachtelt haben, meistens jedoch haben Sie das schließende Tag schlichtweg vergessen.

Element "u" undefined.

Sie verwenden ein Element (hier u), das in der verwendeten (X)HTML-Version nicht enthalten und somit nicht erlaubt ist.

There is no attribute "name".

Sie verwenden ein Attribut (hier name), das in der verwendeten (X)HTML-Version an dieser Stelle nicht erlaubt ist.

Required attribute "alt" not specified.

Sie haben ein erforderliches Attribut nicht angegeben (hier das alt-Attribut des img-Elements).

Character "<" is the first character of a delimiter but occurred as data.

Eine spitze Klammer steht an einer Stelle, an der sie nicht stehen darf. Möglicherweise steht sie irgendwo einsam und allein (beispielsweise 4 < 7), dann können Sie sie ziemlich einfach finden. Häufiger jedoch ist die Meldung eher irreführend. Der Validator zeigt denselben Fehler an, wenn Sie das abschließende Anführungszeichen eines Attributs vergessen (zum Beispiel <p class="error>Es ist ein Fehler aufgetreten.</p>).

Unclosed start-tag requires SHORTTAG YES.

Sie haben ein Start-Tag nicht ordnungsgemäß geschlossen (beispielsweise <div anstatt <div>).

Character "&" is the first character of a delimiter but occurred as data.

Das Dokument enthält ein allein stehendes Ampersand (&). Weshalb das falsch ist und wie Sie das Zeichen korrekt notieren, lesen Sie in Abschnitt 4.1.4.

Cannot generate system identifier for general entity "ap".

Sie haben eine benannte Zeichenreferenz (hier ≈) notiert, die es nicht gibt.

XML Parsing Error: EntityRef: expecting ';'.

Sie haben eine Zeichenreferenz ohne abschließendes Semikolon notiert (beispielsweise &160 anstatt &160;).

Versuchen Sie niemals, die komplette Fehlerliste auf einmal abzuarbeiten, es sei denn, sie besteht nur aus einer Handvoll Meldungen, die Sie unmittelbar zuordnen können. Der W3C-Validator nimmt es sehr genau und gibt für die gleiche Fehlerursache häufig unterschiedliche Meldungen aus. Zudem können Fehler einander bedingen. Beginnen Sie folglich stets am Anfang der Liste, beheben Sie den ersten oder die ersten beiden Fehler und überprüfen Sie Ihr Dokument anschließend erneut. Gehen Sie so Schritt für Schritt vor, bis Ihr Dokument fehlerfrei ist.

Einschränkungen

Ein Validator ist ein gutes Werkzeug, das Webautoren effizient dabei unterstützt, fehlerfreie Dokumente zu erzeugen. Er ist aber lediglich ein Werkzeug. Es ist nicht gesagt, dass Dokumente, die ein Validator als gültig klassifiziert, auch wirklich fehlerfrei im Sinne der Spezifikation sind. Eine DTD kann nicht alle formalen Einschränkungen beschreiben, denen ein Dokumenttyp unterliegt. So lassen sich keine Datentypen wie Integer oder Float definieren; Daten sind praktisch nur Zeichenketten. Das Element

<a href="ich bin kein uri">Anker</a>

beispielsweise ist unsinnig im Sinne der Empfehlung, die als Wert des href-Attributs einen URI fordert, aber es ist gültig im Sinne der DTD, die für das href-Attribut den Inhaltstyp CDATA definiert, also lediglich eine Folge von Zeichen. Darüber hinaus soll nicht unerwähnt bleiben, dass es einige merkwürdig anmutende SGML-Konstrukte gibt, die ein SGML-Validator als gültig erkennt, die Darstellung von Dokumenten jedoch gehörig durcheinanderbringt. Nicht nur

<p><em>Foo</em></p>

ist gültiges HTML. Webautoren dürften auch

<p><em/Foo/</p>

schreiben (Stichwort: Shorttags), es gibt jedoch kaum ein Benutzerprogramm, das dieses Element dann noch anzeigen kann.

Zum Seitenanfang

Schema-Validator

Webautoren, die XHTML schreiben, können die meisten Validatoren derzeit nur mit Einschränkungen verwenden. Die Gründe liegen zum einen in den angesprochenen Beschränkungen von DTDs, zum anderen darin, dass es signifikante Unterschiede zwischen SGML und XML gibt, die bisher nicht weitreichend genug beachtet werden. Beim W3C-Validator wird es noch eine Weile dauern, bis er über eine vollständige XML-Unterstützung verfügt. Es gibt allerdings bereits Abhilfe. Die W3C-Notiz XHTML 1.0 in XML Schema vom September 2002 definiert die XHTML-Varianten Strict, Transitional und Frameset als XML Schema, einem XML-Dokumenttyp, mit dem sich die Struktur und die Daten eines XML-Dokuments wesentlich genauer beschreiben und prüfen lassen als mithilfe von DTDs. Es können unter anderem Datentypen sowie genaue Wertebereichsbeschränkungen angegeben und die formale Grammatik von XHTML dadurch deutlich präziser beschrieben werden. Christoph Schneegans stellt einen Schema-Validator bereit, über den XHTML-Dokumente gegen das entsprechende Schema validiert werden können. Dabei werden Fehler aufgedeckt, die herkömmliche Validatoren nicht finden. Der W3C-Validator beanstandet den fehlerhaften Wert des width-Attributs nicht:

<p><img src="uri" alt="foo" width="bar" /></p>

Der Schema-Validator hingegen erkennt den Fehler und wirft eine Fehlermeldung: The 'width' attribute is invalid.The value 'bar' is invalid according to its datatype 'http://www.w3.org/1999/xhtml:Length'.The Pattern constraint failed.

Abb. 3.6: Der Schema-Validator von Christoph Schneegans

Zum Seitenanfang

Grenzen

Ein weiterer wichtiger Aspekt sollte nicht unerwähnt bleiben: Validatoren überprüfen, ob Dokumente syntaktisch korrekt sind und sich an das vorgegebene Vokabular halten; sie können aber nicht beurteilen, ob Webautoren alle Informationen sinnvoll strukturiert haben oder ob Dokumente barrierefrei und zugänglich sind. Sie könnten auf nahezu alle strukturellen Elemente zugunsten einer reinen div- und span-Suppe verzichtet oder Dutzende von Layouttabellen ineinander verschachtelt haben – das Dokument wäre gültig. Folgender Schachtelsatz (entnommen aus [Schneider 2001]) ist in jeder Hinsicht formal korrekt, dabei aber vollkommen unverständlich.

»Denken Sie, wie schön der Krieger, der die Botschaft, die den Sieg, den die Athener bei Marathon, obwohl sie in der Minderheit waren, nach Athen, das in großer Sorge, ob es die Perser nicht zerstören würden, schwebte, erfochten hatten, verkündete, brachte, starb!«

Niemand würde solche Sätze formulieren. Aber es gibt genügend Webautoren, die vergleichbares Markup schreiben. Prägen Sie sich ein: Gültigkeit ist nur ein Aspekt guten Webdesigns – aber längst nicht der wichtigste (siehe auch [Korpela 2008]).

Zum Seitenanfang

CSS-Validator

Natürlich gibt es auch CSS-Validatoren, also Werkzeuge, die es ermöglichen, Ihre CSS-Stylesheets sowie in XHTML-Dokumente eingebettetes CSS in Bezug auf Standardkonformität zu überprüfen. Der bekannteste und beste CSS-Validator ist der CSS-Validierungsservice des W3C. Wie der W3C Markup Validation Service bietet auch er mehrere Möglichkeiten der Validierung.

Abb. 3.7: Der CSS-Validierungsservice des W3C

Bevor Sie Ihr CSS überprüfen, sollten Sie zunächst sicherstellen, dass die Dokumente, auf die Sie das CSS anwenden, korrekt sind. Fehler im XHTML können zur Folge haben, dass unerwünschte und unerwartete Effekte auftreten, obwohl das CSS fehlerfrei ist.

Auch für die CSS-Validierung gilt: Beheben Sie einen Fehler nach dem anderen und führen Sie mehrere Validierungsabläufe durch, bis Ihre Dokumente und Stylesheets fehlerfrei sind.

Weitere Tipps zur Benutzung des W3C-Online-Validators sowie Erläuterungen zu den häufigsten Fehlermeldungen finden Sie auf der Website von Klaus Langenberg.