Umstellung von HTML auf XHTML

[molily]

Hallo,

Der Artikel rät zu HTML 4 anstatt XHTML 1 als text/html. Er hat jedoch m.E. keine brauchbaren Argumente dafür, sondern irreführende. Das ist ein Schwachpunkt im Artikel. Darauf habe ich hingewiesen. Und ja, der Artikel enthält auch viele unterstützenswerte Aussagen und nützliche Informationen. Die habe ich nicht absichtlich verschwiegen, um ihn in ein schlechtes Licht zu stellen, sondern weil ich mich einfach nicht dazu ausgelassen habe. Ich sehe auch keinen Grund, dies tun zu müssen, nur wenn ich ein spezifisches Argument entkräften will.

Denn man kann (ja: muß) den Text IMHO so interpretieren: Wenn du nicht weißt, warum du XHTML codest (sondern du verwendest XHTML weil es hip ist, oder in deinem Tool voreingestellt, oder ...), dann bedenke ...

Genau in dem Punkt macht der Artikel Fehler, indem er verschweigt, was bei XHTML zu bedenken wäre (leider will der Artikel das offenbar nicht leisten). Er sagt eben nicht, wie man XHTML mit Validatoren anfassen sollte, sondern zieht aus der Unfähigkeit mancher Validatoren einen "Nachteil" für XHTML.

... überspringst die kritischen Anmerkungen/Problemhinweise einfach, und fängst an der Stelle (mitten im Text) an, wo der Autor anfängt aufzulisten, welche Möglichkeiten man hat, mit der gegenwärtigen Situation umzugehen.

Er plädiert offenkundig für nur eine gangbare Möglichkeit, und seine Argumentation dafür ist teilweise irreführend. Sonst müsste er zugestehen, dass XHTML als text/html sehr wohl eine Möglichkeit wäre. Seine Einwände dagegen sind banane, punkt.

Die Aussage ist nach meiner Auffassung: Dein "XHTML" wird als HTML gewertet, und als solches ist es invalide (s. Validator - qed). Nicht mehr, nicht weniger.

Ja, klar, das ist seine Aussage - aber inwiefern soll das problematisch sein? Inwiefern ist das nun ein Argument? Warum ist es nützlich, das zu wissen?
Tag-Soup-Browser können XHTML als text/html problemlos verarbeiten, welchen Wert hat eigentlich dieses ständige theoretische Argument "als HTML validiert wäre es invalide"?

Gerne kann ich Stachowiaks Argumentation noch einmal genauer rekonstruieren. Sie beruht nämlich völlig auf diesem praktisch irrelevanten Argument. Er kommt halt nicht auf abwärtskompatibles XHTML klar. Warum, bleibt im dunkeln:
"All those “Valid XHTML 1.0!” links on the web are really saying “Invalid HTML 4.01!”."
Na und? Wo ist denn bitte das Problem dabei, dass abwärtskompatibles XHTML bedeutet: "actually invalid HTML that’s getting by on the error handling of HTML parsers"? Ist vielleicht von der Theorie her nicht toll, aber schwarz ärgern muss man sich auch nicht, denn in der Praxis hat sich das tausendfach bewährt. Deshalb empfehlen Dokumentationen wie Jendryschiks XHTML als text/html.
Sein Kernthema lautet demnach: "Perhaps you’re just now realizing that your lovingly crafted valid XHTML document is actually invalid HTML."
Dieser Ausgangspunkt ist schon falsch formuliert - für mich ist das für sich genommen kein Problem, über dem ich irgendwie zu grübeln hätte.
Darauf nun die mögliche Antwort: "Stick with the status quo." - Ist schon suggestiv formuliert. Jetzt sind wir gespannt, warum es problematisch ist, sich einfach damit zu arrangieren. Anstatt Argumente zu bringen, warum XHTML als text/html Nachteile bringt, kommt dieses aus den Fingern gesogene Nullargument:
"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".
Stimmt übrigens inhaltlich nicht, weil HTML-Validatoren das Dokument eben nicht parsen, wie Browser es parsen. Browser kennen nur Tag-Soup, Standard-Validatoren legen obskure SGML-Maßstäbe an das Dokument an, die ein Browser nie durchgehen ließe.
Aber das Argument ist eh ein theoretisches... Scheint mir eher ein undefinierbares schlechtes Gefühl zu sein, dass etwas nicht mit rechten Dingen zugeht, wenn man XHTML-Code an Tag-Soup-Parser ausliefert. Weil, das ist ja gar nicht HTML! Deshalb kann es nicht richtig sein! Ach..! - Auch wenn es ganz prächtig funktioniert.

Oder aber, großes Kino, Du hast ein Must-Have-"XML-Tool" an der Hand, das u.a. davor warnt, wenn man (intern oder als externe Resource) z.B. document.write() in einer XHTML-Seite verwendet?

Es ist kein Erfordernis von XML, dass document.write nicht funktioniert, genauso wie eine Zeitlang createElement ohne "NS" nicht funktioniert hat. Das sind keine prinzipiellen Einschränkungen, sondern temporäre. Es ist kein prinzipielles Problem, document.write auf XML umzuschreiben, genauso wie mittlerweile innerHTML im XML-Modus funktioniert.

Natürlich weist kein generischer XML-Editor auf solche Probleme hin, sondern da bedarf es einer Dokumentation der gerade aktuellen Browserlandschaft. Aber ich bezog mich ohnehin nur auf Stachowiaks Aussage, es gäbe nur für HTML ausgereifte Toolchains.

Weder in SELFHTML noch in der JS-Doku bei Mozilla findet sich z.B. bei write() ein Warnhinweis, daß das in XHTML nicht funktioniert

Momentan befasst sich SELFHTML schlichtweg nirgendwo mit XHTML als XML befasst, sondern empfiehlt text/html. Die Ergänzungen, die in punkto XHTML seit Jahren in SELFHTML getätigt wurden, sind marginal.

Also wenn ein Safari-Entwickler im Safari-Blog schreibt, daß der XHTML-Parser vom Safari weniger getestet und fehlerhafter ist, als der HTML-Parser

Klar haben Browser Fehler und Lücken auch nach über sechs Jahren application/xhtml+xml. Vielleicht sollte man die mal dokumentieren und nach und nach angehen, anstatt über XHTML zu weinen und einen Backlash auszurufen - in den Kontext gehört Stachowiaks Artikel, ob er will oder nicht.

Wer bist Du, das besser zu wissen, als ein Safari-Entwickler? Der Safari-Chefentwickler?

Jemand, der Autoritätsargumente nicht gelten lässt, sondern gefälligst eine technische Referenz haben will, die Abweichungen und Probleme dokumentiert.

Da dazu aber offenbar kein Interesse seitens der Browserhersteller besteht, sondern lieber Artikel wie der vorliegende geschrieben werden, gibt es keine Fixes für die entsprechenden Bugs. Was meinst du, wieviel triviale Fehler bzgl. X(HT)ML/DOM in Geckos Bugzilla herumliegen - es sind keine technischen Entscheidungen, sich damit nicht auseinanderzusetzen. Es ist verständlicherweise einfacher, alle Ressourcen auf Tag-Soup zu lenken. So entstehen die Empfehlungen, doch bitte Tag-Soup zu verwenden (Apple, Mozilla), oder Vertröstungen auf eine kommende, ausgereifte Implementierung (Microsoft). Die wirken dann als self-fulfilling prophecy - da kann man auch gleich die XHTML-Unterstützung abschalten.

Bist Du nicht auch der Meinung, daß es einen Grund hat, wenn die Moz-Entwickler auf grundlegende Probleme mit XHTML-Parser in Engines FF <3 verweisen, und selbst für FF 3 noch raten, XHTML auch wirklich nur als XHTML auszuliefern, wenn man diesbezügl. spezifische Features benutzt.

Natürlich hat es Gründe. Und Browserhersteller haben noch viel zu tun, insbesondere beim Scripting von X(HT)ML, wieso sollte ich das bezweifeln? Es hat sich aber auch einiges getan, sodass man sich diese Probleme im Einzelnen anschauen müsste.

was hindert denn z.B. dich selbst daran, deine "XHTML 1.0 strict"-Seiten ggf. als XHTML auszuliefern?

"Meine" XHTML-Seiten stehen in tausenden Kontexten und es gibt jeweils viele gesonderte Gründe. Das reicht von dem Punkt, dass keine automatisierten Wohlgeformtheits-Tests möglich sind, bis zu dem Punkt, dass fremder Code und fremder Content keine Kompatibilität bietet. Zuletzt wüsste ich auch nicht, warum ich es auf Teufelkommraus anstreben sollte; ich erzähle doch ständig, warum ich XHTML einsetze und dass speziell das letztendliche Ausliefern als XHTML an Browser für mich nicht entscheidend ist.

Mathias