molily Navigation

HTML-Dokumentmodelle

Dokumentmodelle vereinfachen das Verständnis der Semantik von Auszeichnungssprachen wie HTML

  1. Zur Einstimmung
  2. Eine mögliche Abstraktion vom Code zum Modell
  3. Grundlagen: HTML-Code als Linearisierung einer Baumstruktur im Speicher
  4. Vokabular der HTML-Syntax
  5. Orientierung durch Markup-Abstraktionsmodelle
  6. Mögliche Veranschaulichungen
    1. Einrückungen im gekürzten Markup
    2. Schachtelmodell
    3. Baumstrukturen
  7. Schlussfolgerungen aus den Veranschaulichungen
  8. Nutzen: Von Objektmodellen zu korrektem Code und sinnvollen Objektstrukturen

Zur Einstimmung

Ein HTML-Dokument ist in der statisch gespeicherten Form zunächst einmal eine Datei – eine Ansammlung von Nullen und Einsen, die für bestimmte Zeichen stehen, zum Beispiel Buchstaben und Zahlen. Diese Aneinandereihung von Zeichen ein Hypertext-Dokument zu nennen, mag selbstverständlich und trivial scheinen, ist jedoch ein riesiger gedanklicher Schritt und eine komplexe Abstraktionsleistung.

Tatsächlich geben diese Nullen und Einsen ein Geflecht von Informationen wieder und schließlich werden daraus im Browser abstrakte Objekte miteinander vernetzter Informationsknoten. Wie läuft eine solche Verarbeitung ab? Welche Modelle gibt es für diesen Weg der Abstraktion? Wie lassen sich die Objektverbindungen veranschaulichen? Und können uns diese Modelle beim Verständnis von HTML und dessen effizienter Anwendung helfen?

Eine mögliche Abstraktion vom Code zum Modell

  1. Eine HTML-Datei, gespeichert auf einer Festplatte oder im Arbeitsspeicher, ist zunächst eine bloße Ansammlung von Nullen und Einsen (oder im physikalischen Sinne: Strom – kein Strom usw.).
  2. Jeweils acht Bit repräsentieren bei dieser Kodierung ein bestimmtes Zeichen. Zwar ist nach der Übertragung sofort ein Muster erkennbar, nämlich die charakteristische HTML-Syntax. Deren Sinn erschließt sich aber erst, wenn die Bedeutung (Semantik) der Bestandteile bekannt ist. Um diesen Zwischenschritt zu veranschaulichen, wurden in der Grafik alle Buchstaben verfremdet.
  3. Die Zeichen fügen sich zu bekannten Wörtern einer natürlichen Sprache zusammen, deren direkten Sinn wir zumindest erahnen können und deren regelmäßiger Zusammenhang sich beschreiben lässt. Die Trennung zwischen natürlicher geschriebener Sprache und Metasprache (Sprache über Sprache) wird erkennbar. Beide folgen unterschiedlichen Mustern.
  4. Wenn die Spracheinheiten in ihrem Sinn entschlüsselt sind, werden die Beziehungen der Teile in Sequenzen (geordnete Abfolgen) und Hierarchien (Verschachtelungen) überführt wurden. Im Gesamtzusammenhang kann letztlich die Bedeutung rekonstruiert werden.

Grundlagen: HTML-Code als Linearisierung einer Baumstruktur im Speicher

Zwar will der englischsprachige Artikel Markup vs. Tag soup darauf hinaus, den Unterschied zwischen beschreibender und sogenannter prozeduraler Textauszeichnung zu erläutern (»HTML is largely about nouns, not verbs«). Dennoch finden sich darin Erläuterungen zum Wesen von Textauszeichnung. Dabei interessiert vor allem der letzte Satz (Hervorhebung und Absatztrennung durch mich):

»A tag is just a marker, like a parenthesis: its role is syntactic only, to group with its matching parenthesis the contents in between, where the block as a whole is given a name for semantic purposes.

Such a name, called the generic identifier, is included in the start-tag because it's syntactically convenient to do so, but this name is not a property of the tag. It's a property of the element for which the tag serves as a delimiter. In other words, all semantics apply to elements: the tags merely locate where these elements are.

Similarly, the scope of the element determines the scope of the semantics to be applied, so proper semantic processing depends critically on such scopes being identifiable.

The syntax to scope an element has three parts: a start, content, and an end. The content in turn consists of other elements (also with generic identifiers as "hooks" to semantics) and possibly text.

The elements form a containment hierarchy that is actually a tree, as a data structure, with all text data at the leaf nodes. In fact, a document with SGML markup is no more than a linearized representation of such a tree, where all text is embedded in markup.«

Freie, interpretierende Übersetzung:

Ein Tag ist nur eine Markierung, wie eine Klammer: Er spielt lediglich eine syntaktische Rolle. Er umgrenzt nämlich zusammen mit der entsprechenden anderen Klammer (dem Gegenstück) den Inhalt dazwischen. Dabei wird dem Block als Ganzes zum Zwecke der Bedeutung (Semantik) ein Name gegeben.

Ein solcher Name, auch generic identifier genannt (etwa: allgemeiner Bezeichner, oder anders aufgefasst: die Bezeichnung, die die Art und Klasse angibt) genannt, wird im Start-Tag untergebracht, weil es sich in syntaktischer Hinsicht anbietet. Dieser Name ist jedoch keine Eigenschaft des Tags, sondern eine Eigenschaft des Elements, dem der Tag als Begrenzer dient. Anders gesagt bezieht sich alle Bedeutung auf die Elemente und alle Bedeutung haftet den Elementen an. Die Tags hingegen legen lediglich fest, wo sich diese Elemente befinden.

Gleichermaßen legt die Ausdehnung des Elements fest, auf welchen Bereich die Bedeutung zutrifft bzw. für welchen Bereich diese gilt. Deshalb hängt die korrekte Verarbeitung gemäß der Bedeutung (Semantik) entscheidend davon ab, ob diese Geltungsbereiche erkennbar und exakt bestimmbar sind.

Es gibt drei syntaktische Teile, die den Umfang eines Elements bestimmen: der Anfang, der Inhalt und das Ende. Der Inhalt selbst wiederum besteht aus anderen Elementen (ebenfalls in Form von Tags als »Angriffspunkte« für das Zuweisen von Bedeutung) und etwa Text.

Die Elemente bilden eine Enthaltenseinshierarchie (Verschachtelungshierarchie), welche wie ein Baum als Datenstruktur organisiert ist – der Baum ist eine in der Informatik bekannte Datenstruktur. An dessen Verzweigungen bzw. Fassungen sind die Textdaten angehängt (wie Blätter oder Früchte). Ein aus SGML- oder XML-Markup bestehendes Dokument ist letztlich nichts anderes als eine linearisierte Darstellungsweise (Abbild, Repräsentation) eines solchen Baumes, bei der der Text in Markup (Auszeichnungen, Markierungen) gefasst wird.

Dieser Satz beschreibt die Prinzipien der Textauszeichnung: Eigentlich haben wir es mit einer hierarchische Baumstruktur mit Verzweigungen und Knoten zu tun. Der HTML-Code, den wir schreiben und ständig vor uns sehen, ist davon nur die linearisierte Repräsentation, also eine textuelle Abbildung, die sich einfacher schreiben, lesen, langfristig speichern und übertragen lässt.

Von spitzen Klammern über Tags hin zu Dokumentmodellen

Um das Wesen von Textauszeichnung zu verstehen, wollen wir dessen Funktionsweise noch einmal rekonstruieren, indem wir uns scheinbar unwissend stellen.

In einem (mit Markup) »ausgezeichneten« Text lassen sich bei naiver Betrachtung lediglich in Größer- und Kleiner-Zeichen gefasste, wenig verständliche Fragmente als Teile der künstlichen Auszeichnungssprache nachweisen. Diese heben sich von der natürlichen Sprache ab und schneiden den den natürlichsprachigen Text ein und unterbrechen ihn immer wieder.

Bei näherer Untersuchung der Metasprache wird deren grundlegende Syntax erkennbar: Diese »spitzen Klammern« trennen natürliche Sprache und Metasprache. Die Bestandteile treten in einem gleichfömigen Schema auf, sie sind nicht willkürlich in den Text eingestreut. Ohne Vorwissen lässt sich feststellen, dass die paarweise auftretenden »Zeichen« Anfang und Ende eines Textbereiches zu markieren scheinen.

(Natürlich besteht Markup aus weiteren syntaktischen Einheiten als elementbildende Tags. Zeichenreferenzen, Kommentare und CDATA-Abschnitte interessieren uns in ihrer syntaktischen Dimension erst einmal nicht, da sie nicht die Daten- und Informationsanordnung betreffen. Meta-Markup wie Dokumenttyp-Deklarationen bildet nur den Rahmen eines Modells und ist für das Verständnis von Textauszeichnung vergleichsweise unwichtig.)

Die Vermutung liegt nahe, dass diese Zeichenpaare der Metasprache etwas über Text zwischen den Begrenzungsmarken aussagen, diesen also in seiner Bedeutung im Gesamttext bestimmen. Diese Markierungen (Tags) finden sich in variantenreicher Ausführung mit Zusätzen, die einem strengen Muster folgen und ihrerseits natürliche Sprache enthalten können. (Gemeint ist hier das, was wir später als Attribute bezeichnen werden.) Damit ist die sprachliche Struktur bereits größtenteils entschlüsselt: Die kleinste Einheit der Auszeichnungssprache ist ein Paar von in Beziehung stehenden Tags.

Zwar wird schnell einsichtig, dass diese Einheiten größtenteils nicht autonom bestehen, sondern ihre Bedeutung mehr oder minder aus ihrer Rolle als Glied eines größeren Zusammenhangs schöpfen, dennoch geht dieses einfache Verständnis zunächst von Einheiten aus, die ohne starken logischen Bezug nebeneinander auftreten.

Für weitere Untersuchungen bietet sich nun die erste Terminologie (d.h. Begriffslehre) an: Die Dreiheit aus einem Anfangs-Tag, dem ausgezeichneten umschlossenen Text sowie dem End-Tag wird als Element bezeichnet. Damit ist der Sprung vom einfachen Tag zu einem einzelnen Textbestandteil geschafft, der durch die Auszeichnungssprache semantisch (d.h. in seiner Bedeutung) erweitert wird. Diese Einzelstruktur steht mit der Gesamtstruktur aller Elemente, dem Dokument, in einer Wechselwirkung und definiert sich wiederum darüber.

Vokabular der HTML-Syntax

Anhand des vorerst wenig ausdifferenzierten Modells bieten sich eindeutige Bezeichnungen für die Codebestandteile an, um den Aufbau eines Hypertextdokuments auf der konkreten Markup-Ebene zu beschreiben. Betrachten wir folgendes einfaches Codebeispiel:

<a href="http://www.example.com/">Beispiellink</a>

Das Beispiel lässt sich in seine Bestandteile zerlegen, die gemäß der »offiziellen« Terminologie von SGML sowie den W3C-HTML-Spezifikationen so genannt werden:

Syntaxbestandteile und deren Bezeichnungen
Bezeichnung Codebestandteil
Element <a href="http://www.example.com/">Beispiellink</a>
Elementname <a href="http://www.example.com/">Beispiellink</a>
Start-Tag <a href="http://www.example.com/">Beispiellink</a>
Elementinhalt <a href="http://www.example.com/">Beispiellink</a>
End-Tag <a href="http://www.example.com/">Beispiellink</a>
Attribut <a href="http://www.example.com/">Beispiellink</a>
Attributname <a href="http://www.example.com/">Beispiellink</a>
Attributwert <a href="http://www.example.com/">Beispiellink</a>

Demzufolge lässt sich der Beispielcode folgendermaßen umschreiben: Ein a-Element (ein Hyperlink) enthält den Text »Beispiellink« (der Bezeichner des Verweises). Das Element besitzt ein href-Attribut mit dem Attributwert »http://www.example.com/« (ein gültiger URI, die auf eine eine Site im World Wide Web zeigt).

Dass wir bereits auf syntaktischer Ebene von »Elementen« reden, ist tatsächlich ein verwirrender Bruch in der Terminologie. Der Begriff »Element« ist eigentlich auf einer abstrakteren Ebene angesiedelt. Auf der Ebene der linearen Darstellungsweise, das heißt auf der Code-Ebene, sehen wir nämlich nur Tags, die Text umschließen. Der Begriff »Element« spielt bereits auf ein Dokumentmodell an, für das der Code nur ein Abbild ist. Siehe dazu die längere Abhandlung Begriffsunterschied Element – Tag?.

Unglücklicherweise wird der Begriff »Tag« nicht nur für die tatsächlichen Start-Tags und End-Tags verwendet, sondern auch für »Element« missbraucht. Die meisten Web-Quellen über HTML müssen erst mit der erwähnten W3C-Terminologie in Übereinstimmung gebracht werden, sodass die wichtigen Unterschiede nicht über den Haufen geworfen werden. In diesem Fall ist eine begriffliche Klarheit und sprachliche Genauigkeit notwendig, da sonst schwere Missverständnisse auftreten.

Orientierung durch Markup-Abstraktionsmodelle

Wozu brauchen wir Modelle, die vom HTML-Code abstrahieren? Welchen praktischen Nutzen haben sie und welche Schlüsse lassen sich aus ihnen ziehen?

CSS und JavaScript nicht ohne Dokumentmodelle denkbar

Spätestens beim Einsatz der Zusatztechniken CSS und JavaScript bleibt man stecken, wenn man HTML nur auf der konkreten Code-Ebene als lose Anhäufung von Tags betrachtet. Sowohl CSS und JavaScript/DOM gehen von einem Dokumentmodell aus und arbeiten vollständig auf dieser Ebene. Sie operieren mit der Datenstruktur des Elementbaumes, wie sie sich im Speicher befindet – mit der linearen Abbildung dieser Struktur mittels Textauszeichnung, Tags usw. haben sie nichts zu tun. Für Webautoren ist es daher unerlässlich, HTML-Dokumente nicht von der Code-Ebene her, sondern von der Ebene eines Dokumentmodells her zu denken. Der HTML-Code ist dementsprechend als sogenannte Linearisierung oder auch Serialisierung dieser Datenstruktur zu verstehen.

Die Grundlagen von CSS, die Selektoren und die Vererbung sowie das Boxmodell und der Elementfluss, sind nur vom zugrunde liegenden Dokumentmodell her zu verstehen. Noch direkter operiert JavaScript mit der Baumstruktur und deren »Knoten«. Dabei werden nicht nur Elemente zum Zwecke der Formatierung angesprochen. JavaScript ist imstande, den gesamten Knotenbaum zu verändern. Dies zeigt einmal mehr, dass das Dokument als die Datenstruktur zu verstehen ist, mit und an der im Speicher des Browser operiert wird.

Semantische Auszeichnung und effiziente Technikverwendung

Dokumentmodelle können dabei helfen, wohlstrukturierte Dokumente zu schreiben, dessen Inhalte bedeutungsreich organisiert sind. Wenn unsinnige Sequenzen und Hierarchien vermieden werden, bleibt der Code schlank und aufgeräumt bleibt. Dies zahlt sich aus, wenn die besagten Zusatztechniken im Hinblick auf Effizienz und Flexibilität eingesetzt werden sollen.

Damit z.B. ein Styleheet einfach warten und ausbauen zu können, ist eine sinnvolle Dokumentstruktur vonnöten. Eine stimmige Verschachtelung ist vor allem wichtig, wenn Elementen abhängig von ihrem Kontext CSS-Formatierungen zugewiesen werden sollen. Das Ziel ist, sie ohne Umstand so allgemeingültig wie möglich adressieren zu können, ohne dass das Markup nachträglich nur zum Zweck des Stylings angepasst werden muss. Nur wenn mehrere Dokumente eine konsistente, voraussehbare Struktur haben, können ausgelagerte, rationalisierte Stylesheets ihre Wirkung entfalten.

Elementbaum und Dokumenthierarchie veranschaulichen

Während wir uns im HTML-Code recht schnell zurechtfinden, haben wir Schwierigkeiten damit, uns stets die entsprechende abstrakte Datenstruktur vor Augen zu führen. Dabei helfen können grafische Darstellungen, die die die Eigenschaften der Datenstruktur veranschaulichen. Wichtig sind zunächst einmal die Beziehungen zwischen den Elementen.

Mögliche Veranschaulichungen

Im Folgenden abstrahieren wir schrittweise vom Code und betrachten verschiedene Möglichkeiten, den Elementbaum zu veranschaulichen. Dieses kurzes XHTML-Dokument wird als Beispiel dienen:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="de" xml:lang="de">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>XHTML-Beispieldokument</title>
</head>
<body>

<h1><abbr title="Erweiterbare Hypertext-Auszeichnungssprache">XHTML</abbr>-Beispieldokument</h1>

<h2>Inhaltsverzeichnis</h2>
<ul id="inhaltsverzeichnis">
<li><a href="#foo" rel="chapter">foo</a></li>
<li><a href="#bar" rel="chapter">bar</a></li>
<li><a href="#baz" rel="chapter">baz</a></li>
</ul>

<h2 id="foo">foo</h2>
<p>foo</p>

<h2 id="bar">bar</h2>
<p>bar</p>

<h2 id="baz">baz</h2>
<p>baz</p>

</body>
</html>

Einrückungen im gekürzten Markup

Die Verschachtelung von Elementen wird oft visuell durch Einrückungen im Code veranschaulicht. Dabei erzeugt jedes Element eine Einrückungs- und Schachtelungsebene. Das Markup-Prüfprogramm des W3C (gemeinhin als »Validator« bekannt) erzeugt bei dem Parameter »Show Parse Tree« mit dem Zusatz »...exclude attributes« eine Ausgabe mit solchen Einrückungen. Bei dieser Darstellung werden alle Attribute entfernt, es werden lediglich Tags zur Begrenzung der Elemente sowie deren eingerückte Inhalte – andere Elemente oder Textknoten – abgebildet. Die Textknoten werden als letztliche Inhalte hervorgehoben.

<html>
  <head>
    <meta>
    </meta>
    <title>
       XHTML-Beispieldokument
    </title>
  </head>
  <body>
    <h1>
      <abbr>
	 XHTML
      </abbr>
       -Beispieldokument
    </h1>
    <h2>
       Inhaltsverzeichnis
    </h2>
    <ul>
      <li>
        <a>
	   foo
        </a>
      </li>
      <li>
        <a>
	   bar
        </a>
      </li>
      <li>
        <a>
	   baz
        </a>
      </li>
    </ul>
    <h2>
       foo
    </h2>
    <p>
       foo
    </p>
    <h2>
       bar
    </h2>
    <p>
       bar
    </p>
    <h2>
       baz
    </h2>
    <p>
       baz
    </p>
  </body>
</html>

Schachtelmodell

Der bereits wie selbstverständlich benutzte Begriff der Verschachtelung eröffnet eine wichtige Sichtweise auf die Dokumentstruktur und erlaubt auch Fragen nach deren Sinnhaftigkeit. Der ursprüngliche, nicht-metaphorische Sinn des Wortes – die Vorstellung von ineinander (wieder-)verpackten Behältnissen als Ordnungsprinzip – lässt sich treffend auf die Unter- und Nebenordnung der Elemente bzw. Knoten übertragen.

Noch anschaulicher ist deshalb eine grafische Darstellung, welche speziell das Konzept der Verschachtelung betont:

  • html
    • head
      • meta
      • title
        • XHTML-Beispieldokument
    • body
      • h1
        • abbr
          • XHTML
        • -Beispieldokument
      • h2
        • Inhaltsverzeichnis
      • ul
        • li
          • a
            • foo
        • li
          • a
            • bar
        • li
          • a
            • baz
      • h2
        • foo
      • p
        • foo
      • h2
        • bar
      • p
        • bar
      • h2
        • baz
      • p
        • baz

Baumstrukturen

Um die Beziehungen der Elemente in der Hierarchie zu bezeichnen, bedient man sich Begriffen der Abstammungslehre und vergleicht die Elementstruktur mit einem Familienstammbaum. Man spricht beispielsweise von Elternelementen, Nachkommens- beziehungsweise Nachfahrenselementen, Kindelementen und Geschwisterelementen.

Diese Benennungen werden auch bei CSS-Selektoren zur Adressierung von Elementen verwendet. Hierbei wird analog von Selektoren für Nachfahren, Kind-Selektoren und Selektoren für benachbarte Elemente gesprochen. (Eigentlich heißt es in etwa »Selektor für benachbarte Geschwisterelemente«. In CSS 3 wird zusätzlich zwischen direkt und indirekt angrenzenden Geschwisterelemente unterschieden.)

Für das Document Object Model (DOM) schließlich ist die Baum-Metapher zentral. Die Einleitung der DOM-Spezifikation enthält eine beispielhafte grafische Darstellung des Objektmodells einer einfachen HTML-Tabelle. Dabei wird die Neben- beziehungsweise Unterordnung der einzelnen Knoten durch eine astartige Struktur abgebildet. Für das genannte Beispieldokument wäre folgende Darstellung möglich:

html
    head
       meta
       title
          XHTML-Beispieldokument
    body
       h1
          abbr
             XHTML
          -Beispieldokument
       h2
          Inhaltsverzeichnis
       ul
          li
             a
                foo
          li
             a
                bar
          li
             a
                baz
       h2
          foo
       p
          foo
       h2
          bar
       p
          bar
       h2
          baz
       p
          baz

Folgendes Diagramm arbeitet den hierarchischen Aspekt der Baumstruktur stärker heraus:

Schlussfolgerungen aus den Veranschaulichungen

Die aufgeführten Visualisierungen haben verschiedene Schwerpunkte und ergänzen sich. Ihnen ist gemein, dass nur Elementknoten berücksichtigt werden. Beispielsweise Attribute gehen in diesen grafischen Darstellungen verloren. Sie müssten im Gefüge als Knoten auftauchen, die den Elementknoten anhaftende anhaften. Diese Beiordnung kann in den Schaubildern, die Sequenz und Hierarchie zweidimensional darstellen, schwer dargestellt werden.

Wird der Code eines Dokuments wie gezeigt veranschaulicht, fallen Sequenzen und Hierarchien stark ins Auge. Das ermöglicht dem Autor, über den Sinn der Verschachtelung und Gruppierungen nachzudenken: Gehört eine bestimmte Information dort eingeordnet und untergebracht? Sind die Aussagen korrekt, die die Elemente über ihre Inhalte machen? Hat der Inhalt diese Bedeutung? Sind logische Abfolgen und Zugehörigkeiten als solche ausgezeichnet? Beruhen die Beziehungen zwischen den Knoten auf nachvollziehbaren Zusammenhängen?

Nutzen: Von Objektmodellen zu korrektem Code und sinnvollen Objektstrukturen

Bei aller Rede davon, dass wir uns HTML-Dokumente auf abstrakter Ebene vorstellen sollten, entwerfen wir nur selten bewusst Dokumente mithilfe von Abstraktionsmodellen, sondern schreiben letztlich vor allem konkreten Code. Dennoch sollte man HTML als eine Sprache, ein Kommunikationsmittel begreifen, mit dem man eine Information entweder zuverlässig oder missverständlich dem Browser und schließlich dem Webseiten-Leser übermitteln kann.

Die Frage ist nun: Wodurch kann diese Kommunikation fehlschlagen? Mit einem Dreischritt können wir uns den (idealen) Einsatz von HTML zwischen Seitenautor und Seitenbesucher veranschaulichen. Dieser entspricht gängigen Kommunikationsmodellen:

1. Informationen in eine Objektstruktur ordnen

Der Seitenautor möchte Informationen mitteilen. Diese ordnet er zunächst in einer einem Knotengeflecht, einer Objektstruktur an, gekennzeichnet durch Verschachtelung und Nebenordnung sowie näher bestimmenden Objekteigenschaften. So entsteht ein zusammenhängendes Dokument.

2. Linearisierung / HTML-Kodierung

Der Seitenautor linearisiert die ihm vorschwebende Dokumentstruktur, indem er sie in HTML mit den bekannten Tags und der bekannten HTML-Syntax kodiert. Die Sprache HTML dient als Austauschmedium. In diesem Klartextformat lässt sich die Objektstruktur als kodierte Information elektronisch übermitteln und im Web anbieten.

3. Dekodierung zurück in die Objektstruktur und Umsetzung

Der Seitenbesucher benutzt einen Webbrowser, um das HTML-Dokument abzurufen und darzustellen. Der Browser muss als erstes die Kodierung wieder rückgängig machen, das heißt den Code wieder in die ursprüngliche Objektstruktur überführen, dessen Linearisierung er ist. Diese Objektstruktur wird dann schließlich interpretiert und dem Leser präsentiert.

An diesen drei Stellen können nun Schwierigkeiten auftreten, die wir vermeiden können:

1. Wie steht es mit der vom Autor entwurfenen Struktur?

Die HTML-Spezifikation unterwirft diese mögliche Objektstruktur strengen Regeln. Im Idealfall folgen die inneren Zusammenhänge des Dokuments einer bestimmten Logik. Willkürliche Beziehungen (z.B. eine Tabellenzelle mitten in einem Absatz) sind weder möglich noch sinnhaft.

Diese Regeln werden oft als rein syntaktische, grammatische Regeln angesehen – vielmehr betreffen sie den logischen Aufbau eines Dokumentes. Bereits auf dieser Ebene muss entsprechende Vorsorge getragen werden.

2. Verlief die Umsetzung in HTML-Code fehlerfrei?

HTML definiert ferner, wie die Objektstruktur korrekt in Code umgewandelt werden muss. Zwar erlaubt der Standard hier einige Spielräume, die aber von etablierten informellen Regeln, wie die HTML-Umsetzung auszusehen hat, eher eingeschränkt als erweitert werden.

3. Kann der Browser zurückschließen auf die Objektstruktur und diese sinnvoll umsetzen?

Der erste Schritt des Browsers ist die syntaktische Analyse des HTML-Codes, das sogenannte Parsen. Tagpaare werden – Wieder in Rückgriff auf die Vorschriften für HTML-Code – in Elementobjekte mit gewissen Eigenschaften und gewissen Beziehungen überführt.

Wenn der Code die gewünschte, in sich logische Objektstruktur korrekt abbildet, sollte es beim Parsen keine Schwierigkeiten geben. Auch bei einigen wenigen überschaubaren Fehlern verhalten sich die Browser tolerant. Syntaktisch eindeutiger Code emöglicht reibungsloses Parsen. Damit wird dem Browser Arbeit erspart, Stolperfallen und Fehlinterpretationen werden vermieden.

Der zweite Schritt ist die Prüfung, ob die logischen Zusammenhänge überhaupt einen Sinn ergeben und in dieser Form verarbeitbar und letztendlich umsetzbar sind. (Technisch gesehen läuft dieser Schritt im Falle von HTML schon parallel zum Parsens ab.)

Im Dokument auftretende semantische Fehler zeigen an diesem Punkt schließlich ihre Wirkung und legen dem Browser besondere Steine in den Weg. Das zeigt sich etwa bei der Anwendung von allgemeinen Formatierungsregeln aus Stylesheets: Für jedes einzelne Element muss anhand seiner zahlreichen Eigenschaften eine Darstellung erstellt werden, die in Wechselwirkung mit den anderen Elementen und deren Eigenschaften tritt. Auch nachdem das Dokument einmal fertig umgesetzt wurde, muss die Objektstruktur während der Ausgabe andauernd von Neuem verarbeitet werden, schließlich ist sie über Schnittstellen wie JavaScript/DOM jederzeit veränderbar.

Diese Prozesse funktionieren nur dann zuverlässig, wenn Markup und Stylesheet konform mit den Regeln gehen, die ein Browser an den Code und die darin ausgedrückte Objektstruktur anlegt. Die gemeinsame Basis kann hier nur der HTML-Standard sein. Der Validator ist ein bewährtes Mittel, um die Kompatibilität eines Dokuments grundlegend zu testen.

Letzte Änderung: 18.03.2007