Umstellung von HTML auf XHTML

[molily]

Hallo,

Wer es weniger überspitzt haben möchte, der findet am Anfang von Hixies Text auch noch einen moderateren Artikel auf dem Blog der WebKit-Entwickler - und AFAIR dort auch noch weitere Links mit entsprechender Meinung.

Dann schauen wir uns doch mal die Argumente gegen XHTML an:

»Another option is ... generate XHTML content but serve it as HTML. The disadvantages here are mainly that you are losing out on HTML validators, which will validate the document in a way that matches how browsers parse it«

Äh?! Logisch: mit stumpfen HTML-Validatoren kann man kein XHTML validieren. Man muss schon die richtigen Tools verwenden. Ein SGML-Parser wie der W3C Markup Validator, der ein bisschen aufgebohrt ist, um auch XML zu schlucken, ist natürlich ungeeignet für XML-Dokumente! In Zeiten, wo man XHTML-Dokumente problemlos gegen XML-Schemata validieren kann, juckt es einen wirklich nicht, dass konzeptionell auf SGML und SGML-artige Tag-Soup ausgerichtete Pseudo-Validatoren ablosen, wenn es um XML-Validierung geht.

Das ist nicht wirklich ein Nachteil von XHTML. Man muss nur irgendeinen validierenden XML-Prozessor kennen (als ob es da keine gäbe?!) oder besser gleich den XHTML Schema Validator.

and that you run the risk of subtle incompatibilities if your document is ever actually processed as XHTML.

Wissen wir doch alles: Kann man aber ganz einfach vermeiden, indem man XML-Tools einsetzt. Die gibts wirklich wie Sand am Meer.

But this also raises the question: what do you think you are getting out of using XHTML?

Ja, wichtige Frage, sollte man sich stellen. Ist aber auch keine rhetorische Frage, wie es Maciej Stachowiak suggeriert; die Antwort lautet nicht einfach »nothing«.

what kind of benefits do you get if in the end it’s just treated as HTML tag soup?

Wenn es *überall* nur als Tag-Soup verarbeitet wird, kann man auch gleich Tag-Soup schreiben, das stimmt. Dass es aber im Browser als Tag-Soup geparst wird, ist nun wirklich nicht entscheidend, wenn andere Fälle existieren.

Dagegen die Argumente für HTML 4:

This way you’ll be using the best-tested mode of web browsers, won’t have to worry as much about weird compatibility issues, and will get the most benefit out of HTML-based toolchains.

Als wäre XML-Parsing nicht »best-tested« und als wäre es Rocket Science, XHTML-Dokumente als XHTML an entsprechend fähige Clients zu liefern. Den letzten Teilsatz verstehe ich einfach nicht, die meisten »Toolchains« sind wohl XML-basiert, da HTML-Parsing außerhalb des Browsers überhaupt keine Rolle spielt. Wohl aber sind XML-Parsing, daran anschließend DOM, XSLT, XPath und Co. mittlerweile in jeder noch so dummen Entwicklungsumgebung möglich.

Mathias