Jens Meiert

(X)HTML 5 und XHTML 2 im Vergleich (xhtml.com)

Jens O. Meiert, 12. März 2007 (↻ 25. November 2007).

Revidierte Übersetzung (anderes Urheberrecht) des englischen Artikels von xhtml.com.

Diese Übersetzung ist möglicherweise veraltet.

Das Rennen um die nächste Markup-Sprache im Internet ist in vollem Gange. Dieser Artikel stellt die Eigenschaften der konkurrierenden Technologien gegenüber und benennt die Stärken und Schwächen beider Ansätze.

Anmerkung des Übersetzers: Während der Artikel inhaltlich vor allem bei den »Stärken« glänzt, sind die unter »Schwächen« aufgeführten Punkte mitunter mit Vorsicht zu genießen; sie entsprechen nicht unbedingt der Einschätzung des Übersetzers. Es darf nicht vergessen werden, dass sich beide Spezifikationen noch in der Entwicklung befinden.

Inhalt

  1. Hintergrund
  2. XHTML 2
    1. Stärken von XHTML 2
    2. Schwächen von XHTML 2
  3. (X)HTML 5
    1. Stärken von (X)HTML 5
    2. Schwächen von (X)HTML 5
  4. Die nächste Markup-Sprache im Internet
  5. Anmerkungen
  6. Mehr zum Thema

Hintergrund

HTML 4 und XHTML 1 haben uns bisher gute Dienste erwiesen, aber beide Spezifikationen haben Ihre Schwächen. Um den Forderungen der Benutzer nach besseren Webapplikationen gerecht zu werden, um mehr Menschen die Möglichkeit zu geben, auf Webinhalte zuzugreifen, unabhängig davon, welches Gerät sie verwenden, und um bessere Suchergebnisse zu erzielen, müssen diese Spezifikationen aktualisiert oder ersetzt werden.

Zwei Spezifikationen schicken sich an, Nachfolger von HTML 4 und XHTML 1 zu werden. Es handelt sich dabei um XHTML 2.0 und »Web Applications 1.0«, gemeinhin unter der Bezeichnung (X)HTML 5 bekannt. Diese Spezifikationen verfolgen unterschiedliche Ansätze, um sich zur nächsten Markup-Sprache im Internet zu mausern.

XHTML 2 ist ein großer Schritt nach vorn bei der Absicht, eine Architektur zu schaffen, die die Basissprache für zahlreiche andere W3C-Technologien darstellen kann. XHTML 2 basiert auf XML, eine Technologie, von der die meisten meinen, dass sie die Nutzung des »vollen Potentials des Internets« ermöglicht. XHTML 2 wurde so definiert, wie eine Markup-Sprache sein sollte – nicht, wie Markup-Sprachen heutzutage verwendet werden.

(X)HTML 5 entspricht einer Erweiterung von HTML 4 und XHTML 1. Es ist ein kleiner Schritt vorwärts, kein großer Schritt in der Art von XHTML 2. Obwohl es sich in den engen Grenzen von HTML 4 und XHTML 1 bewegt, hat (X)HTML 5 clevere Lösungen zur Umgehung einiger Probleme dieser beiden Spezifikationen parat. (X)HTML 5 kann ebenfalls als HTML oder XML ausgeliefert werden. Anders als XHTML 2 wird (X)HTML 5 stark vom aktuellen Stand der Technik (Browser-Technologie &c.) sowie dem gegenwärtigen Gebrauch von Markup beeinflusst.

Sowohl (X)HTML 5 als auch XHTML 2 befinden sich im Zustand eines Arbeitsentwurfs. Beide Spezifikationen werden sich höchstwahrscheinlich noch ändern und Jahre vergehen, bevor sie zu empfohlenen und gebräuchlichen Technologien werden. Dieser Artikel basiert auf den »Working Drafts« der Spezifikationen mit Stand vom Februar 2007.

XHTML 2

Stärken von XHTML 2

Navigationslisten

Navigationslisten definieren Navigationsmenüs. Sie werden durch das Element nl definiert, das ein label-Element mit dem Titel der Liste enthalten muss. Zum Beispiel:

<nl>
  <label>Sie sind hier:</label>
  <li href="/">Startseite</li>
  <li href="/produkte/">Produkte</li>
  <li href="/produkte/widgets/">Widgets</li>
  <li>Funktionen</li>
</nl>

Navigationslisten sind cool!

Erweiterung von Definitionslisten

Definitionslisten (dl-Element) definieren einen Term (dt-Element) und eine Definition (dd-Element). Ein Term kann mehrere Definitionen beinhalten, und eine Definition kann zu mehreren Termen gehören. XHTML 2 bietet die Möglichkeit, Begriffe und Definitionen mithilfe des di-Elements zu gruppieren. Dadurch wird die Beziehung zwischen einem Term und seinen Definitionen deutlicher und resultiert in besser lesbaren Code. Ein Beispiel:

<dl>
  <di>
    <dt>Zentrum</dt>
    <dt>Mittelpunkt</dt>
    <dd>Der Hauptgeschäftsbereich einer Stadt.</dd>
    <dd>Ein Punkt auf einer Linie mit gleichen Abständen zu den Endpunkten.</dd>
  </di>
  <di>
    <dt>Schlüssel</dt>
    <dd>Metallgegenstand, mit dem ein Schloss geöffnet werden kann.</dd>
    <dd>Tätigkeit, die zur Erlangung eines Ziels führt.</dd>
  </di>
</dl>

Diese Verbesserung der Definitionslisten ist cool!

Jedes Element kann ein Hyperlink sein

Zu jedem Element kann ein href-Attribut hinzugefügt werden, um es zu einem Link zu machen. Zum Beispiel:

<q href="http://de.wikipedia.org/wiki/Neil_Armstrong">Dies ist ein kleiner Schritt für einen Mann, ein riesiger Sprung für die Menschheit.</q>

Das ist sehr cool!

acronym gibt es nicht mehr

Viele Autoren wissen nicht, wie sie das Element acronym korrekt einsetzen sollen. XHTML 2 verwendet das Element abbr für jede Art von Abkürzung, einschließlich Akronymen.

Cool!

b, i, small, big, tt, font und basefont gibt es nicht mehr

XHTML 2 verabschiedet sich von diesen Elementen, die strikt zur Formatierung verwendet wurden. Insbesondere wurde das Element font in der Vergangenheit falsch verwendet und hat Autoren davon abgehalten, gutes Markup zu erzeugen.

Extrem cool!

iframe gibt es nicht mehr

Das iframe-Element hat schon immer Probleme für Benutzer verursacht, die unterschiedliche Technologien einsetzen. Dieses Element wird sicher nicht vermisst.

Cool!

Neues Konstrukt für Überschriften

Überschriften sind die wichtigsten Hilfsmittel zur Strukturierung von Webseiten. Dennoch werden Überschriften fast nie korrekt verwendet, da die numerierten Konstrukte für Überschriften (die Elemente h1 bis h6) schwer zu visualisieren sind und es für Autoren nahezu unmöglich ist, sie mit WYSIWYG-Editoren zu verwenden. Numerierte Überschriften sind lineare Konstrukte (sichtbare Elemente), die zur hierarchischen Strukturierung von Daten dienen. Im nachfolgenden Beispiel muss viel Aufwand betrieben werden, um die hierarchische Struktur des Inhalts darzustellen.

<h1>…</h1>
<p>…</p>
<h2>…</h2>
<p>…</p>
<h2>…</h2>
<p>…</p>
<h3>…</h3>
<p>…</p>
<h4>…</h4>
<p>…</p>
<h3>…</h3>
<p>…</p>
<h2>…</h2>
<p>…</p>

Im Gegensatz dazu ermöglicht das neue Überschriftenkonstrukt, das aus h-Elementen und den gruppierenden section-Elementen besteht, die hierarchische Struktur sehr viel einfacher zu modellieren:

<h>…</h>
<p>…</p>
<section>
  <h>…</h>
  <p>…</p>
  <h>…</h>
  <p>…</p>
  <section>
    <h>…</h>
    <p>…</p>
    <section>
      <h>…</h>
      <p>…</p>
    </section>
    <h>…</h>
    <p>…</p>
  </section>
  <h>…</h>
  <p>…</p>
</section>

Das h-Element ist sehr cool!

Verbesserungen für Code-Beispiele

Anstatt pre und code kann das Element blockcode verwendet werden, um Code-Blöcke darzustellen. Zum Beispiel:

<blockcode>
function get_random_name() {
  $rand_name = '';
  for ($i = 1; $i &lt;= 8; $i++) {
    $rand_name .= chr(rand(97, 122));
  }
  return $rand_name;
  }
</blockcode>

Das ist cool!

hr wird durch separator ersetzt

Die Bezeichnung des Elements hr als »horizontal rule« hat Autoren und Entwicklern stets Probleme bereitet. Der Name indiziert, dass es sich dabei um eine horizontale Linie handelt. Das Element ist jedoch vielmehr dazu gedacht, einen Teil eines Dokuments von einem anderen Teil zu trennen. Die Verwendung des Namens separator verhindert dieses Missverständnis.

Das ist cool!

del und ins werden durch das edit-Attribut ersetzt

Das Attribut edit ist viel besser als del und ins geeignet, um veränderte Inhalte anzudeuten. Es kann wie folgt verwendet werden:

<p>Das ist <span edit="deleted">cool</span><span edit="inserted">besonders cool</span>!</p>
Möglichkeit zur Erweiterung der Semantik bestehender Elemente

Mit Hilfe des role-Attributs kann die Bedeutung eines bestehenden Elements erweitert werden. Dies kann Suchmaschinen dabei helfen, Internetseiten besser zu indizieren. Das folgende Beispiel zeigt, wie zu einer Navigationsliste die Information hinzugefügt werden kann, dass sie wie eine Breadcrumb verwendet wird.

<nl role="breadcrumbs">
  <label>Sie sind hier:</label>
  <li href="/">Startseite</li>
  <li href="/produkte/">Produkte</li>
  <li href="/produkte/widgets/">Widgets</li>
  <li>Funktionen</li>
</nl>

Die technische Grundlage für die Verwendung des role-Attributs wird in »Embedding RDF in XHTML« beschrieben. Dadurch wird XHTML 2 in hohem Maße erweiterbar und kann zum wichtigsten Werkzeug heranwachsen, durch das das Internet sein »volles Potential« ausschöpfen kann.

Das role-Attribut ist extrem cool!

Schwächen von XHTML 2

Das a-Element existiert weiterhin

Da man das href-Attribut bei jedem Element verwenden kann, ist das Element a eigentlich (Anmerkung des Übersetzers: Betonung auf eigentlich) überflüssig. Für Autoren ist es eher verwirrend, dass es weiterhin in der Spezifikation enthalten ist. Beispielsweise kann in HTML 4 und XHTML 1 das id-Attribut verwendet werden, um jedes Element zum Ziel eines Ankers zu machen. Zum Beispiel:

<h2 id="einleitung">Einleitung</h2>

So werden jedoch die meisten Autoren das a-Element für solche Referenzen verwenden. Zum Beispiel:

<h2><a name="einleitung">Einleitung</a></h2>

Am a-Element festzuhalten ist uncool!

Das img-Element existiert weiterhin

In XHTML 2 kann das Element object alles, was das img-Element kann. Die Spezifikation sagt, dass das img-Element weiterhin verwendet werden kann, um den Übergang zu XHTML 2 zu erleichtern. In der Praxis wird es Autoren eher verunsichern. Das weiterhin unterstützte img-Element ist kein leeres Element mehr, sondern kann Inhalt enthalten. Zum Beispiel:

<img src="w3c.png">W3C</img>

Wenn ein Element in XHTML 2 denselben Namen wie ein Element in HTML 4 oder XHTML 1 hat, seine Bedeutung aber unterschiedlich ist, dann wird dies sehr wahrscheinlich Verwirrung und Diskussionen auslösen.

Am img-Element festzuhalten ist uncool!

Unterstützung von numerierten Überschriften

Da das h-Element der bessere Ansatz ist, um Überschriften zu erzeugen, sind numerierte Überschriften überflüssig. Die Unterstützung beider Ansätze – sowohl des h-Elements als auch numerierter Überschriften – wird Autoren verunsichern.

Numerierte Überschriften sind sehr uncool!

XHTML 2 wird hinter verschlossenen Türen entwickelt

Es ist nur sehr wenig über die Gruppe bekannt, die XHTML 2 – möglicherweise die nächste Markup-Sprache des Internets – entwickelt. Leute, das ist keine »Stinktierarbeit« für eine geheime Waffe. Lasst die Sonne herein!

(X)HTML 5

Stärken von (X)HTML 5

Die Idee strukturierender Elemente

(X)HTML 5 führt neue Elemente ein, die den Inhalt einer Internetseite strukturieren. Dadurch soll es Suchmaschinen und ähnlichen Technologien leichter gemacht werden, den Inhalt der Seite zu verarbeiten. Die Verwendung dieser neuen Elemente kann dazu führen, dass der Quelltext der Seite besser lesbar wird.

Die Idee strukturierender Elemente ist cool! Allerdings ist die Technik zur Umsetzung strukturierender Elemente eher uncool.

dialog-Element

Das dialog-Element repräsentiert eine Unterhaltung. Es enthält dt-Elemente, um den Sprecher zu identifizieren, und dd-Elemente, um die Zitate des Sprechers zu zeigen. Zum Beispiel:

<dialog>
  <dt>Costello</dt>
  <dd>Look, you gotta first baseman?</dd>
  <dt>Abbott</dt>
  <dd>Certainly.</dd>
  <dt>Costello</dt>
  <dd>Who’s playing first?</dd>
  <dt>Abbott</dt>
  <dd>That’s right.</dd>
  <dt>Costello</dt>
  <dd>When you pay off the first baseman every month, who gets the money?</dd>
  <dt>Abbott</dt>
  <dd>Every dollar of it.</dd>
</dialog>

Das ist cool!

figure-Element

In gedruckten Publikationen (Bücher, Zeitschriften, Magazine &c.) werden Medienobjekte (Fotos, Illustrationen, Graphiken &c.) meist mit einer Über- oder Unterschrift versehen. Die im Internet verwendeten Markup-Sprachen besaßen dafür bisher keine Modellierungsmöglichkeit. Das figure-Element mit dem legend-Unterelement kann jetzt verwendet werden, um Bilder zu beschriften. Zum Beispiel:

<figure>
  <legend>Quelle: Agentur, 2007</legend>
  <img src="mustermann.jpg" alt="Foto: Max Mustermann" />
</figure>

Das ist sehr cool!

mark-Element

Das mark-Element repräsentiert markierten oder hervorgehobenen Text. Dies ist eine sehr nützliche Funktion, wenn Webseiten dynamisch als Ergebnis einer Schlüsselwort-Suche erzeugt werden. Wenn das Schlüsselwort in einer Seite enthalten ist, dann kann es mit dem mark-Element hervorgehoben werden. Als Beispiel dient eine Antwort auf die Suchanfrage »Schnee«. Die daraufhin generierte Webseite kann folgendes Snippet beinhalten:

<p>Ein <m>Schnee</m>mann ist eine menschenähnliche Skulptur, die aus <m>Schnee</m> besteht.</p>

Das ist cool!

Erweiterung des input-Elements

Das input-Element wurde erweitert, um die Datentypen E-Mail, URL, Datum, Zeit und numerische Werte zu unterstützen. Das bedeutet, dass mehr Gültigkeitsprüfungen auf dem Client statt auf dem Server durchgeführt werden können. (Anmerkung des Übersetzers: Siehe auch Web Forms 2.0.)

Cool!

Offener Prozess

Der Entwicklungsprozess von (X)HTML 5 ist offener als der von XHTML 2. Jeder ist willkommen, sich auf der (X)HTML-5-Mailing-Liste zu beteiligen.

Offene Prozesse sind cool!

Schwächen von (X)HTML 5

Umsetzung strukturierender Elemente

Die Idee hinter »strukturierenden Elementen« ist fantastisch, allerdings ist die Umsetzung in (X)HTML 5 schrecklich. Einige der Definitionen sind zudem sehr verwirrend. Zum Beispiel:

Das Element aside repräsentiert einen Abschnitt einer Seite, der inhaltlich ähnlich dem Text ist, der das Element aside umschließt, der jedoch vom Rest des Inhalts getrennt werden kann. In Print-Medien werden solche Abschnitte oft durch sogenannte »Sidebars« repräsentiert.

Wäre ein div-Element mit einem role-Attribut nicht besser dazu geeignet und zudem noch einfacher zu implementieren?

Ein weiteres strukturierendes Element ist nav, das einen Abschnitt repräsentieren soll, der Links zu anderen Seiten enthält. Benötigt man ein Element wie nav? Das nl-Konstrukt aus XHTML 2 ist dazu besser geeignet.

Die Umsetzung strukturierender Elemente ist uncool und sollte verbessert werden.

Probleme aus HTML 4 und XHTML 1 wurden übernommen

Da (X)HTML 5 versucht, abwärtskompatibel zu sein, werden viele Probleme von HTML 4 und XHTML 1 in (X)HTML 5 übernommen. Die Spezifikation sollte nicht abwärtskompatibel sein. Die bessere Lösung wäre, wenn die verarbeitenden Programme abwärtskompatibel sind, indem sie mehrere Spezifikationen unterstützen. (Anmerkung des Übersetzers: Diese Kompatibilität ist jedoch erklärtes Ziel der Spezifikation.)

Die Fortsetzung der Ungereimtheiten von HTML 4 und XHTML 1, wie beispielsweise numerierte Überschriften und die Elemente i, b, small, iframe und font ist überhaupt nicht cool!

(X)HTML 5 hält sich nicht an die (X)HTML-5-Vorgaben

(X)HTML 5 versucht zu HTML 4 und XHTML 1 abwärtskompatibel zu sein. Elemente wie big, acronym, u und tt sind jedoch offenbar nicht Teil der Spezifikation und die Elemente i und small haben eine veränderte Bedeutung. So zum Beispiel definiert die HTML-4.01-Spezifikation i und small wie folgt:

i: Gibt Text kursiv aus.

small: Gibt Text mit kleinerer Schriftgröße aus.

In (X)HTML 5 haben i und small eine neue Bedeutung:

Das i-Element stellt einen Textteil mit einer anderen Stimme, in einer anderen Stimmung oder in einer anderen Art abweichend vom restlichen Text dar, wie beispielsweise eine taxonomische Bezeichnung, einen technischen Ausdruck oder einen idiomatischen Ausdruck in einer anderen Sprache, einen Gedanken oder ein Ausdruck, der typischerweise typographisch hervorgehoben wird.

Das small-Element stellt Kleingedrucktes (der Teil eines Dokuments, der oft rechtliche Hinweise wie Kopierrechte oder andere Einschränkungen enthält) oder Fußnoten anderer Art dar.

Indem die Bedeutung der Elemente i und small verändert wird, besteht (Anmerkung des Übersetzers: theoretisch) keine Abwärtskompatibilität zu HTML 4 und XHTML 1 mehr. Abwärtskompatibel bedeutet nämlich, dass ein Programm, das HTML 5 verarbeitet, ein HTML-4-Dokument genauso handhaben kann, wie dies ein Programm, das HTML 4 verarbeitet, tun würde. Wenn HTML 5 den Anspruch der Abwärtskompatibilität erhebt, dann sollte ein Element ohne Bedeutung in HTML 4 auch in HTML 5 keine Bedeutung haben.

Sich nicht an die eigenen Vorgaben zu halten ist uncool!

Wie jetzt? Das font-Element wird weiterhin unterstützt?

Ja, (X)HTML 5 unterstützt des font-Element, wenn ein Dokument mit Hilfe eines WYSIWYG-Editors erstellt wird. Was ist der Grund dafür? Warum stellen WYSIWYG-Editoren eine Ausnahme dar?

Das ist besonders uncool!

WYSIWYG-Signatur

Dokumente, die mit Hilfe eines WYSIWYG-Editors erstellt wurden, müssen folgende WYSIWYG-Signatur im head-Element enthalten:

<meta name="generator" content="(WYSIWYG editor)" />

oder

<meta name="generator" content="Sample Editor 1.0 (WYSIWYG editor)" />

Was ist der Grund dafür? Soll dies eine Rechtfertigung für schlechten Code sein? Soll man dadurch darauf hingewiesen werden, dass die Seite schlecht umgesetzt ist, weil sie mit einem WYSIWYG-Editor erstellt wurde? Und was ist, wenn nur ein Teil der Seite mit Hilfe eines WYSIWYG-Editors erstellt wurde?

Das ist unverständlich und absolut uncool!

Vordefinierte Klassennamen

Anmerkung des Übersetzers: HTML 5 sieht keine vordefinierten Klassen mehr vor.

Vordefinierte Klassennamen entsprechen reservierten CSS-Klassennamen, die für (X)HTML-5-User-Agents eine bestimmte Bedeutung haben können. Im folgenden Beispiel ist der Klassenname copyright ein vordefinierter Name:

<p class="copyright">…</p>

Weitere vordefinierte Klassennamen sind error, example, issue, note, search und warning. Um die Sache noch komplizierter zu machen, dürfen einige vordefinierte Klassennamen nur bei bestimmten Elementen verwendet werden. Beispielsweise darf copyright nur in Verbindung mit p und span eingesetzt werden. Der Klassenname error darf nur bei p, section, span und strong Verwendung finden.

Ein Problem von vordefinierten Klassennamen ist, dass folgendes Beispiel nichts ausdrückt:

<p class="important">

… während folgendes Beispiel jedoch sehr wohl eine Bedeutung hat:

<p class="copyright">

Durch Überladung von Klassenattributen ist es sehr schwer, die Bedeutung eines Konstrukts zu interpretieren. Was soll beispielsweise folgendes bedeuten?

<p class="important copyright issue">

Vordefinierte Klassennamen hindern Autoren zudem daran, Klassennamen frei zu vergeben. Außerdem: Was passiert, wenn ein Autor einen aktuell nicht vordefinierten Klassennamen verwendet, der später zu einem vordefinierten Namen wird? Wird dadurch die Bedeutung des Inhalts verändert?

XHTML 2 hat dafür mit dem role-Attribut eine wesentlich bessere Lösung gefunden. Die vordefinierten Klassennamen in (X)HTML 5 sind sehr uncool!

HTML 5 im Vergleich mit XHTML 5

Der Versuch, die Debatte HTML gegen XHTML zu beenden, führt in der (X)HTML-Spezifikation dazu, dass das Thema noch komplexer wird. Die (X)HTML-5-Spezifikation sagt »Autoren werden dazu aufgefordert, XML nicht im Web zu verwenden«, während das W3C daran festhält, dass XML die Zukunft des Internets darstellt? Das ist sehr verwirrend und außerordentlich uncool!

Ein überstürzter Prozess

(X)HTML 5 ist eine Reaktion auf die zögerlichen Fortschritte, die das W3C in der Bereitstellung eines Ersatzes von HTML 4 und XHTML 1 macht. Allerdings erscheint der Entwicklungsprozess von (X)HTML 5 übereilt und man hat das Gefühl, dass die Spezifikation aus dem Nichts erschienen und »mit der heißen Nadel gestrickt« ist. Einige der direkt in den Prozess involvierten Parteien meinen, dass die Zeitpläne und Meilensteine in der Entwicklung der Spezifikation vollkommen unrealistisch sind.

Die nächste Markup-Sprache im Internet

Sowohl (X)HTML 5 als auch XHTML 2 versuchen, HTML 4 und XHTML 1 zu ersetzen. Zu diesem frühen Zeitpunkt des Entwicklungsprozesses haben einige Browser-Hersteller bereits Ihre Präferenzen zugunsten der einen oder der anderen Spezifikation geäußert. Das Ergebnis dieser hastigen und nicht öffentlichen Beratungen ist, dass die Gemeinschaft, die die Standards im Internet setzt, polarisiert wird. Während die beiden Spezifikationen konkreter werden, werden viele Marketing-Ausgaben zugunsten der einen oder anderen Spezifikation getätigt, und alles deutet auf einen »Krieg« der Standards hin.

Wir sind alle Teilhaber dieses Prozesses, da das Internet der Allgemeinheit gehört. Nur eine ehrliche und offene Debatte kann sicherstellen, dass wirklich die beste Spezifikation als Sieger hervorgeht. (Anmerkung des Übersetzers: … so denn keine Koexistenz bevorzugt wird.)

Anmerkungen

Ähnliche Themen

Das könnte Sie ebenfalls interessieren:

Schwerpunkt:

Fehler entdeckt? Belohnung! E-Mail an jens@meiert.com.

Sie sind hier: meiert.comPublikationen → (X)HTML 5 und XHTML 2 im Vergleich (xhtml.com)

Stand: 25. November 2007.