molily Navigation

XHTML wird zu Grabe getragen

In letzter Zeit wechseln viele Meinungsführer demonstrativ zurück von XHTML 1.0 auf HTML 4.01. Genauso sang- und klangvoll propagierten sie vor einigen Jahren den Wechsel zu XHTML: XHTML sei neu, besser, strenger und XML sei die Zukunft.

Diese Euphorie wurde nicht von technischen Fakten getragen, sondern von Missverständnissen, falschen Versprechungen und Zukunftsprognosen, wie sich das Web in fünf bis zehn Jahren entwickeln könnte und ob man mit seinem Markup auf diese Entwicklung vorbereitet sei. Die Annahme, XHTML 2 würde die langfristige Nachfolge von HTML 4 antreten, begründete den XHTML-Hype und nicht die konkreten, kurzfristigen Vorteile von XHTML 1. So setzte schnell eine grundlegende Kritik von XML im Web und insbesondere dessen Modell der drakonischen Fehlerbehandlung ein. Diese Kritik führte zur Entstehung von HTML 5 und zur heutigen weitgehenden Ablehnung von XHTML.

Hypes und Trends statt nüchterne Betrachtungen der Vor- und Nachteile

Während dieser ganzen Zeit gab es nur wenige, die versucht haben, die Vorteile und die nützliche Anwendungsfälle von XHTML für Webautoren herauszuarbeiten. – Positiv zu nennen ist hier die Einführung in XHTML, CSS und Webdesign von Michael Jendryschik und das XHTML-Einmaleins von Christoph Schneegans. – Nur vereinzelt wurde XHTML 1.0 als das betrachtet, was es ist: Schlicht eine Reformulierung von HTML 4 in XML. Wenige pickten sich die brauchbaren Aspekte des XHTML-Konzepts heraus, um von dieser Technik zu profitieren, ohne sich die unerwünschten Effekte einzuhandeln. Stattdessen war die Diskussion vollends eingenommen über »Neuheit« und Zukunftsfähigkeit.

Heutzutage wird der XHTML-Hype zu Grabe getragen, ohne dass sich diese verstellte Sicht geändert hätte. Auch im Jahr 2009 sucht man nüchterne Betrachtungen vergebens. Man richtet sich nach Trends und migriert bestehende, funktionierende XHTML-Sites offenbar ohne konkreten Anlass auf HTML. Auch heute wird nicht gefragt: Was bringt mir XHTML im Vergleich zu HTML? Wer schon 2002 keine konkreten Gründe für den XHTML-Einsatz angeführt und die XHTML-Vorteile überhaupt nicht genutzt hat, für den ist eine Rückkehr zu HTML 4 heute wieder nur eine Frage von Trends und Prognosen.

Das Bemühen um Zukunftsfähigkeit ist zweifelsohne wichtig, jedoch sollten Spekulationen über die Zukunft des Webs einer Kosten-Nutzen-Analyse weichen. Wer von den XHTML -Features nicht zu profitieren glaubt, wer XHTML-Dokumente an keiner Stelle als XML verarbeitet, wer um die Fallstricke von HTML 4 weiß, kann natürlich problemlos HTML 4 verwenden und ist damit gut beraten. Die neuerliche Verdammung von XHTML ist jedoch – genauso wie seine damalige Propagierung – unreflektiert und betrachtet den Diskussionsgegenstand nicht.

Die Vor- und Nachteile von XHTML sind hinreichend bekannt, ebenso ist der sinnvolle und weitgehend unproblematische Einsatz dokumentiert. HTML-kompatibles XHTML ist bewährt und etabliert. Es ist, richtig eingesetzt, Teil beider Welten: Fehlertoleranz auf der Browserseite (durch Auslieferung als text/html) und eindeutige, strenge und überprüfbare Regeln auf der Autorenseite. XHTML kann als XML verarbeitet werden, aber auch als HTML.

Das große Problem von XHTML war ohnehin weniger XHTML selbst oder die schlechte Browser-Unterstützung, sondern der Hype darum, der sich für die Eigenheiten von XHTML, für seine Stärken und Schwächen nicht wirklich interessierte. Das schlagkräftigste Argumente der XHTML-Skeptiker war daher, dass die Leute XHTML missverstehen und falsch einsetzen könnten. Damit haben sie leider recht behalten – sogar noch im Moment seiner Abschaffung missverstehen die meisten XHTML.

Kompatibilität zu HTML 5

Ein vielfach angeführter Grund der Rückkehr von XHTML 1 auf HTML 4 ist die angestrebte Kompatibilität mit der Zukunftstechnik HTML 5. Manche neue Sites setzen direkt einen HTML-5-DOCTYPE (<!DOCTYPE html>) ein, verwenden Elemente der entstehenden HTML-5-Spezifikation und nutzen experimentelle HTML-5-Validatoren. Doch was bedeutet Kompatibilität zu HTML 5?

Um das Verhältnis zwischen HTML 4 und HTML 5 zu verstehen, muss man folgendes beachten: Die HTML-5-Spezifikation definiert nicht in erster Linie eine Markup-Sprache, d.h. eine textuelle Wiedergabe eines Dokuments, sondern ein abstraktes Dokumentmodell (DOM), eine Repräsentation im Speicher (»in-memory representation«). Diese Repräsentation wird »DOM5 HTML« genannt.

Erst daran anschließend werden zwei sogenannte Serialisierungen definiert, die dieses Dokument textuell ausdrücken: Eine HTML-Syntax, genannt »HTML5«, und eine XHTML-Syntax, genannt »XHTML5«. Theoretisch wären weitere denkbar.

Die erste Serialisierung ist an die SGML-Anwendung HTML 4 angelehnt, definiert jedoch letztlich eine eigene Syntax mit eindeutigen, fehlertoleranten Parsing-Regeln. Diese Serialisierung zielt auf Kompatibilität mit den bestehenden Tag-Soup-Parsern und mit den tatsächlich bestehenden Websites – gerade nicht auf detailgetreue Übereinstimmung mit HTML 4 als SGML-Sprache.

Die zweite Serialisierung ist eine klassische und reine XML-Anwendung, die nur auf Programme zielt, die XML und XHTML verarbeiten können. Viele der verbreiteten Browser fallen also heraus, was den derzeitigen Einsatz von XHTML 5 im Web unsinnig macht. Einen »Kompatibilitätsmodus« wie bei XHTML 1, der eine Verarbeitung sowohl als Tag-Soup als auch als XML vorsieht, gibt es bei XHTML 5 absichtlich nicht.

HTML 5 löst den Gegensatz zwischen HTML und XHTML auf

Mit der Loslösung von SGML und DTD-Grammatiken überwindet HTML 5 viele Probleme und Unstimmigkeiten von HTML 4, von denen sich auch XHTML 1 positiv abgesetzt hat. Dies nimmt die Spannung aus der Frage »HTML 4 oder XHTML 1?«, indem das Beste von beiden vereint wird. Die entstehenden HTML-5-Validatoren legen strengere formale Grammatiken an, die die Erfordernisse der Spezifikation genauer wiedergeben, so wie wir es von der XHTML-Validierung mit XML-Schemata kennen. Gleichzeitig sind die Parsing-Regeln für die HTML5-Serialisierung liberal und erlauben auch die bei XHTML 1 typische Schreibweise von leeren Elementen (z.B. <br />).

Daher ist es kein Problem, ein HTML-4.01-Dokument auf HTML 5 umzustellen – aber es ist nicht signifikant mehr Aufwand, ein gewöhnliches HTML-kompatibles XHTML-1.0-Dokument auf HTML 5 umzustellen und es bei Bedarf (vorerst außerhalb von Browsern) als XHTML 5 zu verarbeiten.

Ein Beispiel: Um die in XHTML 1.0 geschriebene XHTML-1.0-Spezifikation für HTML 5 fit zu machen, sind nur wenige Schritte nötig: Der DOCTYPE wird auf <!DOCTYPE html> gekürzt, die xmlns-Angabe fällt weg. Ferner wird die XML-Deklaration entfernt – in der Praxis hat nahezu kein XHTML-Dokument eine solche, weil sie im IE 6 den meistens unerwünschten Quirks-Rendermodus auslöst, in welchem der Browser verschiedene Webstandards ignoriert. Schließlich sind es noch viele name-Attribute bei a-Elementen, die dieses Beispieldokument von der HTML-5-Konformität trennen. Solche name-Attribute für Linkanker sind seit HTML 4 nicht mehr notwendig, es reichen id-Attribute. Die name-Attribute wurden zur Unterstützung von Browsern wie Netscape 4 eingesetzt, die den HTML-4-Standard noch nicht umsetzten.

Dieses Beispiel zeigt, dass der jüngste Wirbel um HTML 4 versus XHTML 1 die konkrete Kompatibilität mit HTML 5 nur oberflächlich betrachtet. Die vermeintliche bessere Zukunftsfähigkeit von HTML 4, die zunehmend angesichts des Fortschrittes von HTML 5 gepredigt wird, hat wieder einmal wenig mit der tatsächlichen technischen Sachlage zu tun. Es gilt, endlich zu einer nüchternen und fundierten Analyse zu kommen, die die Webautoren informiert, aufklärt und ihnen eine kompetente Wahl ermöglicht, anstatt ihnen das Blaue vom Himmel zu versprechen oder den Teufel an die Wand zu malen.

Weiterführende Artikel: