SELFHTML Weblog - Ergänzung zur Dokumentation Übersicht

Shooting-Star XHTML

Mittlerweile gehört es zum guten Ton in der Webauthoring-Szene, neue Websites konsequent mit XHTML 1.0 anstatt HTML 4.01 zu entwickeln. Obwohl die oberflächlichen Unterschiede zwischen HTML und XHTML zunächst gering sind, wird ein riesiger Reibach um die Fragen »HTML oder XHTML« und »XHTML als text/html versus application/xhtml+xml« gemacht. Ich möchte diese Diskussion, die bereits seit Jahren läuft, hier nicht vollständig wiedergeben oder weiterführen, sondern verweise lediglich auf meine Linksammlung zum Thema XHTML.

Wie fortschrittlich ist XHTML tatsächlich?

Es gibt sicher ein paar schlagende Argumente, warum Anfänger gleich XHTML 1.0 Strict lernen sollten, man denke an die gelungene Einführung in XHTML, CSS und Webdesign. Die meisten restlichen Argumente für die vermeintliche Fortschrittlichkeit und Zukunftsfähigkeit von XHTML lösen sich allerdings in Luft auf, wenn man sich die Praxis ansieht.

Einige Beobachtungen scheinen mir Konsens zu sein: Allgemein sind XHTML-Autoren nicht über den eigentlichen Sinn von XHTML informiert oder auch nicht interessiert. Die wenigsten XHTML-Dokumente, die momentan geschrieben werden, genügen den Ansprüchen der zuständigen Webstandards. Und selbst wenn die XHTML-Dokumente korrekt sind, dann werden sie praktisch sowieso an keiner Stelle als XML verarbeitet. Den meisten XHTML-Autoren ist die fehlende Konformität deshalb gleichgültig. Unter dem Strich hat die Neuformulierung von HTML in XML also wenig gebracht, die neuen Möglichkeiten können nicht genutzt werden bzw. werden schlichtweg nicht genutzt.

XHTML entmystifizieren

Das kleine Fazit für mich als XHTML-Enthusiasten ist, vor einer oberflächlichen Beschäftigung mit XHTML zu warnen (siehe etwa diesen Beitrag speziell zur Kodierungsfrage). Wer auf XHTML-Syntax umsteigt, weil XHTML ständig im Zusammenhang mit »modern« und »Webstandards« benutzt wird, der erweist dem Fortschritt wahrscheinlich eher einen Bärendienst. Das wurde schon vor vielen Jahren postuliert. Die »Energie des Verstehens« erlaubt den effektiven und aufgeklärten XHTML-Einsatz. Schreibt man XHTML hingegen aus einem Halbwissen heraus, so sind diese Dokumente oft entgegen der Erwartung in keiner Hinsicht besser oder zukunftsfähiger als übliches HTML.

Das soll keine elitäre Position sein, die XHTML nur eingeweihten Spezialisten vorbehält, die sich durch intensives Studium qualifizieren. Der besonnene Einsatz von XHTML ist jedem möglich, die Regeln für wohlgeformtes XML und standardkonformes XHTML sind vergleichsweise überschaubar. Schwieriger wird es, wenn man XHTML-Dokumente als »echtes« XHTML mit dem MIME-Typ application/xhtml+xml an entsprechend fähige Browser ausliefern möchte, siehe etwa The perils of using XHTML properly.

Werkzeuge für korrektes XHTML

Neben all diesen Schwierigkeiten bringt XHTML einen ganz konkreten Vorteil, um den es hier eigentlich gehen soll: Im Vergleich zu HTML ist die Syntax strenger. Die SGML-Deklaration und die Dokumenttyp-Deklaration von HTML erlauben einige unschöne Alternativ- und Kurzschreibweisen, das Konzept der Wohlgeformtheit fehlt gänzlich. In XHTML kann man saubereren Code schreiben, der klaren Syntaxregeln folgt.

Das bekannteste Werkzeug zur Überprüfung der (X)HTML-Syntax ist der W3C Markup Validation Service. Der W3C-Validator setzt allerdings momentan einen aufgebohrten SGML-Parser ein, der XML nicht vollständig und korrekt unterstützt. Für die Validierung von XHTML ist der W3C-Validator daher ungeeignet. Nicht alle XHTML-Syntaxfehler werden bemängelt bzw. die Fehlermeldungen beziehen sich auf SGML anstatt auf XML. Im SELFHTML-Forum kommen immer wieder entsprechende Fragen auf, siehe etwa Vertraue nicht dem W3C-Validator und SGML-Parser verschluckt sich.

Das Relikt der DTD-Validierung

Es gibt noch einen weiteren Grund, warum der W3C-Validator für XHTML nur zweite Wahl ist. Er überprüft die Syntax des Dokuments anhand der Dokumenttyp-Definitionen aus dem XHTML-Standard. Das dafür verwendete Format XML-DTD ist vergleichsweise beschränkt und erlaubt nicht, gewisse rein syntaktische Anforderungen des HTML-Standards maschinenlesbar auszudrücken. Die Alternativsprache XML-Schema löst dieses Problem zumindest teilweise. Das W3C arbeitet daran, für XHTML 1.0 bzw. das modularisierte XHTML Grammatiken in XML-Schema zur Verfügung zu stellen. (Offiziell maßgeblich für XHTML 1.0 ist allerdings nach wie vor die DTD – XHTML 1.0 ist sozusagen eingefroren, die Entwicklung läuft weiter bei modularisiertem XHTML und XHTML 2.)

Schema-Validatoren für XHTML

Wer XHTML schreibt, sollte deshalb von der Möglichkeit der Schema-Validierung Gebrauch machen. Eine Schema-Validierung erlaubt vor allem, die Korrektheit von bestimmten Attributwerten zu überprüfen, für die die XHTML-DTDs fälschlicherweise Freitext (CDATA) erlauben. Folgende Validatoren sind brauchbare Alternativen zum W3C-Validator:

• Validome von Thomas Mell und anderen, auch erreichbar unter validator.de.selfhtml.org
• XML schema validator von Christoph Schneegans

Für Umsteiger wird die Schema-Validierung einige bisher unbekannte Fehler offenbaren. Die Überprüfung mit einem ordentlichen XML-Parser und die Schema-Validierung garantieren, dass die Vorteile von XHTML tatsächlich genutzt werden können – wenn man daran interessiert ist. Ich verarbeite z.B. gerne XHTML-Dokumente serverseitig mit der DOM-Erweiterung von PHP 5. Wohlgeformtes Markup ist dafür die Voraussetzung.

Möglichkeiten und Grenzen von Validierung

Nicht vergessen sollte man, dass strengenommen kein Validator die Standardkonformität eines Dokuments prüfen kann. Validierung wird im Kontext des Webdesigns mit Webstandards für gewöhnlich stark überschätzt. Die Regeln und Empfehlungen des HTML-Standards sowie dessen »Geist« sind nicht maschinell ausdrückbar. Ein Validator prüft lediglich die Syntax hinsichtlich einer Grammatik, die wiederum in einer anderen Computersprache ausgedrückt ist, welche gewissen Beschränkungen unterliegt. Selbst Schema-valider XHTML-Code kann nur ein Grundstein für eine technische solide und letztlich erfolgreiche Website sein.