Umstellung von HTML auf XHTML

[Cybaer]

Hi,

also das ist jetzt nicht das erste Mal, daß ich den Eindruck habe, daß Du mit einem eigenen Link-Titel Meinung machen willst, obwohl das der eigentliche (Seiten-)Titel und Inhalt der verlinkten Resource nicht her gibt. :-/

Dann schauen wir uns doch mal die Argumente gegen XHTML an:

Hier ist es diese Verlinkung. Das ist IMHO kein Text mit "Argumenten gegen XHTML", sondern er heißt "Understanding HTML, XML and XHTML". Es geht hier (und acuh z.B. bei Hixies Text) nicht um eine prinzipielle Verdammung/Schlechtmachung von XHTML (und also auch keine Argumentation gegen XHTML), sondern um das Bewußtmachen einer möglichen Problematik aufgrund der Unterschiede! 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 ...

Soweit, so schlecht. Nun sollte man also meinen, Du würdest dich dann wenigstens mit etwaigen "Argumenten gegen XHTML" (oder wie auch immer) beschäftigen. Was machst Du aber? Du ...

»Another option is ... generate XHTML content but serve it as HTML. 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«

... ü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. Und dabei steigst Du bei Punkt 3 (von 4) ein (OK, "another option" weist ja darauf hin, daß das nicht alles war).

Äh?! Logisch: mit stumpfen HTML-Validatoren kann man kein XHTML validieren. Man muss schon die richtigen Tools verwenden.

IMHO hast Du das falsch verstanden. 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.

Wenn man aber den Text bis zu der Stelle gelesen hat, dann wäre das zu interpretieren als: *Unschön, aber kein wirkliches Problem!* (im Sinne von "das ist das Haupt-'Problem' - also echt nicht der Aufreger").

Weitere Aussage: Es *kann* (nicht muß) zu einem Problem kommen, *wenn* das XHTML-Dokument dann wirklich auch mal als XHTML ausgeliefert wird. Ja, das ist halt Fakt und das:

Wissen wir doch alles

Nur: Wen meinst Du mit "wir"? Dich? Mich? Tim? Ingo? Cheatah? Struppi? Gunnar? ...

Ja, ich glaube auch, daß "wir" das wissen. Dafür würde ich sogar meine Hand ins Feuer legen. :)

Aber so wie unsere Milchstraße nur ein Fliegenschiß im Universum ist, so sind die hiesigen Stammposter (zuzügl. aller Webautoren, die das ebenfalls wissen), nur ein Fliegenschiß im Kosmos aller Webautoren. Und die allermeisten Webautoren wissen es eben nicht - was sie von XHTML natürlich nicht abhält.

Kann man aber ganz einfach vermeiden, indem man XML-Tools einsetzt. Die gibts wirklich wie Sand am Meer.

Hmm, ja. So wie ich das überschaue, ist das also dein einziges Argument: Nimm die richtigen Tools und alles wird gut.

Wenn ich besonders gehässig wäre und es nicht besser wüßte, dann würde ich jetzt wohl antworten: Die "subtilen Inkompatibilitäten" sind zu subtil, als daß Du sie erkannt hättest! >;->

OK, Du weißt es, hast es aber auf die Schnelle nicht bedacht. 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?

Klar, kann man nicht nur wissen, daß write() in XML nicht funktioniert (oder anderes in JS einfach anders funktioniert), mindestens als *bewußter* XHTML- & JS-Coder *muß* man solche Inlompatibilitäten kennen. Allein die Realität sieht anders aus ...

Und BTW: Weder in SELFHTML noch in der JS-Doku bei Mozilla findet sich z.B. bei write() ein Warnhinweis, daß das in XHTML nicht funktioniert (bei SELFHTML weder bei der Methodenbeschreibung, noch im Kapitel Unterschiede zw. HTML und XHTML). Tja, sehr leicht zu durchschauen für XHTML-Anfänger ... :-/

But this also raises the question: what do you think you are getting out of using XHTML?
Ja, wichtige Frage, sollte man sich stellen. Ist aber auch keine rhetorische Frage, wie es Maciej Stachowiak suggeriert; die Antwort lautet nicht einfach »nothing«.

Hier begehst Du IMHO einen Denkfehler. "Nothing" ist *nicht* die "allgemeingültige" Antwort auf diese vermeintlich rhetorische Frage. Könnte es nicht sein, daß der Autor dies, ähnlich wie Du, als eine Kernfrage ansieht? Und das sie auch nur bedingt  rhetorisch ist (zumindet, was die Allgemeinheit angeht)? Sein Credo kann auch einfach lauten: Kannst du die Frage nicht wirklich beantworten (also z.B. so, wie Du sie für dich beantworten kannst), dann hast Du von XHTML eher Nachteile zu erwarten, als Vorteile.

Das betrifft also (X)HTML-Anfänger/Laien, nicht Profis wie dich.

Und BTW: an welche Zielgruppe wird sich ein Text mit dem Titel "Understanding HTML, XML and XHTML" wohl hauptsächlich wenden? An (X)HTML-Newbies, oder an XML-Experten? =:-)

IMHO ist seine Empfehlung (immer seine Zielgruppe im Auge habend) auch nicht anders, als deine an moor ... :)

... nur begründeter.

Wenn es *überall* nur als Tag-Soup verarbeitet wird, kann man auch gleich Tag-Soup schreiben, das stimmt. Dass es aber im Browser als Tag-Soup geparst wird, ist nun wirklich nicht entscheidend, wenn andere Fälle existieren.
(...)
Als wäre XML-Parsing nicht »best-tested« und als wäre es Rocket Science, XHTML-Dokumente als XHTML an entsprechend fähige Clients zu liefern.

Also wenn ein Safari-Entwickler im Safari-Blog schreibt, daß der XHTML-Parser vom Safari weniger getestet und fehlerhafter ist, als der HTML-Parser (was Wunder: viele HTML-Seiten = viele Fehler schnell auffällig, kaum echte XHTML-Seiten = wenige Fehler auffällig), und daß das, ganz im Vertrauen und verlinkt, beim Mozilla auch nicht anders ist, dann finde ich deine Bermerkungen "wenn andere Fälle existieren" und "'best-tested' XML-Parsing" einfach nur daneben. Wer bist Du, das besser zu wissen, als ein Safari-Entwickler? Der Safari-Chefentwickler?

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. "Normales" XHTML aber bitte doch als HTML auch an den FF 3 ausliefern soll - obwohl der ja bekanntlich via Request-Header mitteilt, er würde auch XHTML verarbeiten?

Mit den nun, nach Abzug von FF & Safari, übriggebliebenen "anderen Fällen", wird der Otto-Normal-HTML-Anfänger wohl eher weniger zu tun haben ...

Und BTW: Nein, "Rocket Science" ist es wirklich nicht (auch wenn man die in den Kommentaren geposteten PHP-Beispiele nun wirklich nicht unverändert übernehmen sollte =:-/), aber was hindert denn z.B. dich selbst daran, deine "XHTML 1.0 strict"-Seiten ggf. als XHTML auszuliefern? Ich hab's mal gerade getestet: Egal ob ich XML akzeptiere oder nicht, ausgeliefert wird nur HTML ...

Wohl aber sind XML-Parsing, daran anschließend DOM, XSLT, XPath und Co. mittlerweile in jeder noch so dummen Entwicklungsumgebung möglich.

Ja, da sind wir uns bestimmt einig: In einer perfekten Welt, wo wunderbare XML-Tools zum Einsatz kommen bei Entwicklern (und sonstigen Mitarbeitern, die sich mit dem Webauftritt beschäftigen), die wirklich wissen, was sie tun, für Clients von Programmierern, die es auch wissen, ist X(HT)ML ohne jeden Zweifel die Beste aller Möglichkeiten.

Wenn Du diese Welt gefunden hast, sag mir bitte Bescheid ... ;)

Gruß, Cybaer