7 Kommentare

XHTML und Schema-Validierung

Überlegter Einsatz von XHTML und Werkzeuge zur Validierung

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:

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.

eingeordnet unter:

veröffentlicht von molily

Kommentieren ist für diesen Artikel deaktiviert.

  1. Der Beitrag und besonders das "moralische Schlusswort" gefallen mir sehr gut!

  2. Den W3C-Validator setze ich nur noch auf die Schnelle mal ein, um die üblichen Tipp-Syntaxfehler aufzuspüren. Ansonsten validiere ich mit dem Schema-Validator von Schneegans.

    Ich vertrete immer den Standpunkt, dass korrekte (valide) Syntax einfach in der gleichen Art und Weise die formale Grundlage ist für ordentliche Dokumente wie ein fehlerfreies Deutsch (Grammatik, Zeichensetzung, Rechtschreibung) für ordentlich geschriebene Texte. Es ist schlicht eine Qualitätsfrage.

    Übrigens – darauf wird selten hingewiesen – ist Validierung, wenn man sie konsequent und akribisch betreiben will, gerade bei häufig aktualisierten Dokumenten (wie z.B. Blogs) eine kontinuierlich notwendige Angelegenheit. Besonders dann, wenn die publizierten Artikel nicht bloß Plain-Text sind, sondern im Editor nach Bedarf noch mit spezifischen HTML-Tags ausgezeichnet werden.

  3. Was mir in Deinem Beitrag fehlt, sind zwei, drei konkrete Beispiele dafür, wie landläufig Fehler gemacht werden beim Verfassen von XML-orientiertem XHTML. Wo liegen die Knackpunkte?

  4. Ich finde es fehlt die knackige Aussage. Beispiel: OK, nicht jedes XHTML wird erschöpfend genutzt. Aber was sag mit das? Wird da Potential verschenkt? Hat man unnötigen Aufwand... Grüße, Lu

  5. Gerrit,

    ein üblicher Fehler ist die fehlende Kodierungsangabe, siehe den verlinkten Thread. In XML gibt es feste Regeln, wie die Kodierung eines Dokuments bestimmt wird, Stichwort Content-Type-Header, XML-Deklaration, Standardkodierung UTF-8. Viele XHTML-Dokumente nutzen ISO 8859-1 oder ähnliches, ohne eine entsprechende Angabe in der XML-Deklaration – ein Grund ist der kaputte Doctype-Switch des IE 6. Sobald ein echter XML-Parser ein solches Dokument verarbeiten will, hagelt es »fatale« Fehler gemäß XML. Den W3C-Validator scheren diese Regeln nicht, siehe Umstimmigkeiten bei der Bestimmung der Kodierung von XHTML-Dokumenten (das war ursprünglich eine Kritik am Validome – der macht das mittlerweile korrekt, genauso wie Christoph Schneegans’ Validator).

    Lu,

    Dass das Potential von XHTML weder bekannt ist noch genutzt wird, ist die eine Sache. Die andere Sache ist, dass viele glauben, sie könnten irgendwann die Früchte ernten, die sie durch den Gebrauch von XHTML jetzt sähen. Die meisten Evangelisten versprechen ihnen nämlich das Blaue vom Himmel. Das sowieso schwammige Argument der Zukunftsfähigkeit verliert gänzlich seine Kraft, wenn viele zwar XHTML verwenden, die wenigsten aber dessen Regeln einhalten.

    Unnötiger Aufwand entsteht, wenn Webautoren in einer Hauruck-Aktion auf XHTML umsteigen, ohne Möglichkeiten und Implikationen zu verstehen. Wer diese nicht einigermaßen abschätzen kann, der lädt sich mit XHTML nur Probleme auf, die sich früher oder später zeigen.

    Daher: Wer HTML 4 meistert und in XHTML mittelfristig keine handfesten Vorteile sieht, sollte m.M.n. mit HTML 4 weiterarbeiten. Ich habe zwar ein m.E. handfestes Argument vorgestellt – die strenge Überprüfbarkeit von XHTML im Vergleich mit den Syntaxperversitäten von HTML –, aber dies alleine wiegt die vielen Fallstricke nicht auf.

    Es sei hier noch einmal direkt auf das XHTML-Einmaleins hingewiesen.

  6. Hallo molily,

    danke für Dein Kommentar. Ich finde das ist eine ganz gute Zusammenfassung: XHTML lohnt nicht in jedem Fall, es hat meist nur theoretische Vorteile. Wer aber ohnehin neu schreibt und beides beherscht oder schwerwiegende Gründe für XHTML hat, ist damit besser bedient. Für alle anderen Fälle -und das sind sicherlich einige- ist HTML4 genau so OK und ein Zusatzaufwand oft nicht gerechtfertigt.

    .lu

  7. XHTML ist schlicht einfacher und klarer als HTML 4. Das ist der Grund, warum ich es seit Jahren konsequent einsetze und auch anderen empfehle. Wenn ich einen HTML-4-Mix aus Groß- und Kleinschreibung, fehlenden Anführungszeichen in Attributen oder fehlenden Endtags sehe, bekomme ich kalte Füße.

    Mag ja sein, dass sich die SF-Fantasien, was alles mit XHTML gemixt werden kann, sich in naher Zukunft nicht durchsetzen. Bisher überzeugt mich auch noch nicht XHTML 2, da sind mir die Arbeiten an Web Applications 1.0 näher. Trotzdem gewinnen andere XML-Formate wie RDF, RSS oder SVG im Web an Bedeutung, die ich mir durchaus als eingebettete Lösungen in XHTML vorstellen kann. Indem ich Daten im Blog, im CMS oder statisch ablege, die nicht XML-Konform sind, verschließe ich mich dieser Entwicklung.

    Übrigens – darauf wird selten hingewiesen – ist Validierung, wenn man sie konsequent und akribisch betreiben will, gerade bei häufig aktualisierten Dokumenten (wie z.B. Blogs) eine kontinuierlich notwendige Angelegenheit.
    Für mich unverständlich, dass die Validierung nicht schon während der Eingabe in den Tools vorgenommen wird. Gerade bei Blogs und einfachen CMSs sind die Autoren meistens nicht so gut geschult, dass sie sauberes (X)HTML beherrschen. Und da ist XHTML ebenfalls einfacher zu validieren als eine SGML-Sprache. Ich stehe auf dem Standpunkt, dass SGML-basierendes HTML wenig Sinn macht. Auch fehlerhaftes XHTML lässt sich besser lesen und verarbeiten, egal ob vom Menschen oder von der Maschine. Dass bei einem Umstieg von HTML auf XHTML besondere Probleme auftreten sehe ich nicht. Wer Anfangs Fehler macht, wird nicht gleich mit einer XML-Fehlermeldung auf seinen Seiten bestraft.