Wenn ich ein neues Webprojekt anfange, stelle ich mir fast jedes Mal wieder die Frage nach dem Doctype. Warum ich das tue? Zur Selbstüberprüfung und um mich zu zwingen den Nutzen für das jeweilige Szenario neu zu bewerten. Mit der Aussicht auf HTML 5 und XHTML 2 ist es nun wieder an der Zeit die Standards neu zu betrachten.
Diese Spezifikationen stehen zur Verfügung:
- HTML 4.01 Strict
- HTML 4.01 Transitional
- XHTML 1.0 Strict
- XHTML 1.0 Transitional
- XHTML 1.1
HTML, XHTML und die tag soup
Die HTML-Spezifikationen basieren auf SGML. Also einer Dokumentbeschreibungssprache. XHTML basiert auf der SGML-Teilmenge XML und ist damit genauer und einfacherer zu parsen. Während HTML kleinere Fehler (vor allem nicht geschlossene Tags) schon mal verzeiht, endet das bei XML schnell mit einem Parse Error. Denn alle Browser verwenden sogenannte tag soup parser. Der Parser geht dabei davon aus, dass das HTML generell semantisch nicht korrekt ist, versucht es aber dennoch darzustellen. Nicht so bei XHTML, dort werden, und sollen den Spezifikationen entsprechend, Fehler nicht korrigiert werden. Also ist nicht nur die Wohlgeformtheit in XHTML wichtig sondern vielmehr auch die semantische Richtigkeit.
Sprachräume & MIME-Type
XHTML bietet XML-bedingt einige Möglichkeiten, die HTML nicht beiten kann. So wie z.B. MathML und andere XML-spezifische Vorteile. XHTML ist aber bei seiner Spezifikation so angelegt worden, dass es die gleichen Elemente, Attribute und Verschachtelungesregeln wie HTML kennt. Dies sollte auch gewährleisten das XHTML von Browsern dargestellt werden kann die keine XML-Verarbeitung bieten. Das funktioniert so gut, dass XHTML- wie HTML-Dokumente angezeigt werden. D.h. aber auch das sie nicht als XML verarbeitet werden und somit die XML-Vorteile nicht entfalten können. Das funktioniert aber nur solange der MIME-Type stimmt. Und zwar es der HTML-MIME-Type “text/html” ist. Wird XHTML mit application/xhtml+xml ausgeliefert, wird es auch als XML behandelt und unterliegt gänzlich anderen Spezifikationen und auch Parserbedingungen. Daraus ergeben sich u.a. Vorteile bei der Verarbeitungsgeschwindigkeit. Aber versteht ein Browser (vor allem der Internet Explorer) dies nicht, wird allerhöchstens – wie auch beim kleinsten Fehler – nur eine unschöne Fehlermeldung und keine schicke web2.0-Website angezeigt.
Strict oder Transitional?
Diese Frage stellt sich mir viel eher als das ständige HTML vs. XHTML, wie hier, hier oder auch hier.
Transitional bedeutet dabei eine mildere Auslegung der W3C-Spezifikationen. So sind zwischen <body></body> unformatierter Text und auch die target-Eigenschaft für Links erlaubt. Strict dagegen, handhabt das etwas enger. Stellt aber – bei semantisch korrektem Markup – CSS-basierte Layouts browserübergreifend (ausgenommen der IE5.5, natürlich) wesentlich stabiler dar.
Fazit
Daraus ergibt sich für mich kein erkennbarer Vorteil von XHTML gegenüber HTML. Denn die Frage nach Wohlgeformtheit stellt sich für mich nicht. Egal welche Spezifikation ich nutze, Wohlgeformtheit ist ein Muss für mich. Genauso wie valider Quellcode und vor allem semantische Richtigkeit. Immer wieder lese ich aber XHTML sei besser. Woher dieser Mythos stammt, keine Ahnung. Anstatt Zeit und Energie in die meistens unnötige Diskussion ob HTML oder XHTML zu verwenden sei zu stecken, sollte man sich vielmehr Gedanken über die richtige Semantik machen. Denn mit der sieht es auf vielen Webseiten viel schlimmer aus als mit der Richtigkeit von Spezifikationen.
Die Diskussion ob (X)HTML 5 und XHTML 2 dürfte ebenfalls interessant werden. Mal sehen was die Zukunft bringt…