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.