Das Thema ist in letzter Zeit etwas in den Hintergrund geraten. Peter Kröner hat
es in seiner Linkliste
wieder an das Licht der Öffentlichkeit gezogen: Webseiten in XHTML, die aber als
HTML-Dokumente ausgeliefert werden. Er bezieht sich hier auf einen
Artikel
aus dem ITPastorn Blog. Die dort vorgebrachten Argumente klingen zunächst vernünftig.
Aber es gibt dort einen entscheidenden Fehler. So heisst es unter
Counterargument: You can do that equally well in regular HTML
:
The primary counterargument usually sounds like this: "But you don't need XHTML syntax. Nothing is topping you from using lower case tag names and attributes or the optional closing tags in regular HTML, if you wish." True. But nothing is enforcing it either! And there is no tool available for testing it, at least none that I know of.
Der Gedanke dahinter ist falsch. Wer XHTML Syntax verwendet, und das Dokument dann
aber als HTML liefert, setzt dieses Dokument nicht einem genau prüfenden XML Parser
vor (enforcing
), sondern einem HTML Parser. Und dieser
enforced
gar Nichts. Und hier liegt das eigentliche Problem. Wer XHTML
Syntax verwendet, glaubt, den besseren Code zu liefern. Weil XHTML ja angeblich besser
ist als HTML. Doch wenn dieses XHTML Dokument als HTML geliefert wird, ist das
Etikettenschwindel und damit eher schlechterer Code. Denn da stehen Dinge drin, wie
z.B. der DOCTYPE, die einfach nicht stimmen. Und die angebliche Prüfung des XML
Codes findet nicht statt.
Was ich nachvollziehen und unterstützen kann, das ist, den XHTML Coding Stil auch für HTML Dokumente zu verwenden. Das geht problemlos und ist sehr empfehlenswert. Doch so zu tun, als ob ein HTML-Dokument durch Verwendung des XHTML Coding Stils bereits ein XHTML Dokument wäre, das ist fatal.
Was die Verwendung (und Lehre) des XHTML Coding Stils angeht, kann ich dem Autor des ITPasotns Blog nur beipflichten. Aber was nichtsdestotrotz HTML ist und bleibt, sollte auch HTML genannt werden. Alles Andere ist Etikettenschwindel und nützt letztendliche Niemandem.
Die Verwendung von echtem XHTML (wobei Clientseitig ein echter XML Parser das Dokument sehr genau und gnadenlos prüft) hat so seine Probleme. Das Wichtigste heisst Microsoft, da deren Browser bis heute echtes XHTML nicht darstellen können. Für die Mehrheit der Webseiten ist daher die Verwendung von HTML statt XHTML immer noch das Mittel der Wahl. Hier bei Rorkvell, wo ich gerne neueste Techniken einsetze, habe ich dieses Dilemma folgendermaßen gelöst: Zu jeder HTML-Seite gibt es eine äquivalente XHTML-Seite. Genau genommen ist die XHTML-Seite sogar das Ausgangsdokument, und die HTML-Seite wird daraus per XSL erzeugt. Die Wahl, welches von beiden Dokumenten gesendet wird, wird über automatic content negotiation vorgenommen. Darüberhinaus gibt es in jeder der Versionen unten im Footer einen Link zur jeweils anderen Version, so dass jederzeit die Möglichkeit einer manuellen Wahl besteht. So vereine ich so weit wie möglich die Vorteile beider Welten.
