Irgendwie ist es schon verrückt: XHTML ist nun nach knapp 8 Jahren recht gut im weltweiten Netz etabliert, da veröffentlicht das W3-Consortium den Entwurf (Working Draft) für HTML 5. Nachdem jahrelang mit allerlei (guten) Argumenten der Umstieg auf XHTML beworben und fokussiert wurde, scheint man nun einen Schritt zurück zu machen.
Der Grund dafür dürfte unter anderem der zunehmende Druck seitens der Browser-Hersteller sein. Schliesslich kam der „initiale Zündfunke“ für die Neuauflage von HTML von der „Web Hypertext Application Technology Working Group (WHATWG)“ – einer Initiative einzelner Personen von Apple, der Mozilla Foundation und Opera Software. Nachdem die WHATWG die theoretischen Grundsteine für HTML 5 gelegt hat, arbeitet sie nun gemeinsam mit dem W3C am zukünftigen Standard.
Die Kerngedanken des Entwurfes für HTML 5 klingen prinzipiell erstmal recht viel versprechend, sinnvoll und nachvollziehbar – der Nachfolger von HTML 4.0 könnte eine Reihe interessanter Neuerungen und Möglichkeiten mit sich bringen. Jedoch arbeitet das W3C parallel an XHTML 2, was dem interessierten Webentwickler natürlich die Frage aufzwingt, wofür die Entwicklung zweier konkurrierender Auszeichnungssprachen nützlich sein soll.
Um dies vielleicht etwas näher zu erörtern, sollten wir zunächst einen kurzen Blick auf die Techniken hinter HTML und XHTML werfen.
SGML und XML – die Motoren unter (X)HTML-Haube
SGML ist eine standardisierte Metasprache, die seit Mitte der 80er am Markt etabliert ist. HTML bis einschliesslich HTML 4 und deren Derivate wurden mit Hilfe von SGML definiert. „Normale“ HTML-Seiten werden daher vom Browser mit Hilfe des SGML-Parsers interpretiert.
Nachdem SGML zwar äußerst ausgereift jedoch auch sehr umfangreich und anspruchsvoll ist, wurde bald der Ruf nach einer abspeckten Version von SGML laut, welche nur die wirklich wichtigen Bestandteile enthält. Dieser Wunsch wurde später durch XML umgesetzt.
Durch die zunehmenden Bedeutung von XML in den unterschiedlichsten Einsatzgebieten beschloss man in Folge ein HTML zu etablieren, was statt mit SGML nun mit XML formuliert werden sollte. Das Resultat war XHTML, welches seit Anfang 2000 in der Version 1.0 als offizielle Empfehlung des W3C vorliegt. Für die Interpretation von XHTML-Seiten im Browser des Benuters wird somit der XML-Parser bemüht und nicht der SGML-Parser.
Soweit die Theorie.
Die Entscheidung für die Wahl des richtigen Parsers ist jedoch nicht (allein) von der Dokumenttyp-Deklaration im Kopf der Datei abhängig sondern vielmehr vom MIME-Typ der gelieferten Datei.
Da der XML-Parser nur 100% konformen Code verarbeiten kann, bricht er ab sobald ein Fehler im XML bzw. XHTML-Dokument auftritt. Da dies gerade bei Webseiten eher unerwünscht ist (speziell bei der Vewendung von CM-Systemen kann sich immer mal ein falsches Zeichen einschummeln), werden XHTML-Dokumente in der Praxis nach wie vor mit den MIME-Typ „text/html“ ausgeliefert. Eigentlich ist für die Auslieferung von XML-Dokumenten „application/xml“ bzw. für XHTML-Dokumente „application/xhtml+xml“ vorgesehen. Durch diese Auslieferung als „text/html“ greift der Browser auf seinen SGML-basierten HTML-Parser zurück und nutzt nicht seinen XML-Parser. Dadurch werden auch Dokumente mit syntaktischen Fehlern – mehr oder weniger gut – dargestellt. Die Verarbeitung des Dokuments bricht nicht ab.
Das bedeutet also, dass mit XHTML zwar die Vorzüge von XML bei der Auszeichnung des Dokuments genutzt werden, beim Ausliefern der Seiten an den Browser wird aber aus „Vorsicht“ weiterhin der herkömmliche MIME-Typ genutzt. Für den darstellenden Browser ist es also völlig egal, ob die Seiten mit HTML oder XHTML ausgezeichnet wurden.
Wieso überhaupt XHTML?
Nachdem man sich also vor Augen geführt hat, das HTML viel fehlertoleranter ist als XHTML (streng genommen ist XHTML überhaupt nicht fehlertolerant) und somit auch bei Fehlern seitens des Webentwicklers die Seiten noch anzeigt, stellt man sich die Frage, wieso eine Umstellung von HTML auf XHTML angestrebt wird. HTML scheint doch die einfacher Lösung zu sein?!
Befürworter von XHTML führen hier an, dass viele HTML-Dokumente ein sehr schlechtes Markup enthalten und es dadurch zu Darstellungsfehlern kommen kann. Bei XHTML kann dies aufgrund der strengen Konventionen nicht passieren (bei Verwendung des XML-Parsers), da fehlerhafte Dokumente nicht interpretiert werden.
Desweiteren können XHTML-Dokumente ohne Modifikationen in XML-Werkzeugen angezeigt, verarbeitet und geprüft werden. Somit ist es also (theoretisch) z.B. möglich, die Inhalte eines XHTML-Dokumentes in „Adobe Indesign“ über den XML-Import direkt in ein Print-Layout zu übernehmen.
Zudem lassen sich mehrere Dokumente, welche auf XML basieren, ineinander verschachteln. So wäre es möglich, die XML-Daten einer SVG-Grafik direkt (!) in ein XHTML-Dokument zu übernehmen ohne die Datei auf dem bisherigen Weg zu referenzieren.
Das sind zwar alles sehr einleuchtende und gute Gründe für XHTML, aber was bringt es am Ende den Nutzer? Dem „Otto-Normal-Surfer“ vor seinem heimischen PC oder Mac? Irgendwie nicht viel.
Dann doch lieber (wieder) HTML?
Warum nicht?! Da die theoretischen Vorteile von XHTML gegenüber HTML in der Praxis eher selten zum Tragen kommen, spricht prinzipiell nichts gegen die vermeintlich alte Technik. Eine Weiterentwicklung von HTML scheint daher durchaus sinnvoll und gerechtfertigt. Was jedoch keinen Sinn macht, ist die parallele Entwicklung zweier Standards. Ob HTML oder XHTML ist im Grunde egal – wichtig ist lediglich, das es EINEN Standard gibt. Alles Andere führt nur zur Verwirrung seitens der Webentwickler und sorgt für zusätzlichen Aufwand bei der Entwicklung von Webbrowsern. Da in der Praxis XHTML-Seiten häufig immer noch als HTML ausgeliefert werden, HTML viel toleranter gegenüber Fehlern ist und etwas mehr Freiheiten erlaubt, plädiere ich persönlich für HTML 5 anstatt XHTML 2. Aber darüber lässt sich sicher streiten.
Bis aus dem Working Draft zu HTML 5 eine offizielle Recommendation wird, werden sicher noch zwei bis drei Jahre ins Land gehen. Bleibt also abzuwarten, wie sich das entwickelt.