Umstellung von HTML auf XHTML

[moor]

Hallihallo!
Ich habe in Selfhtml ein Kapitel zu den Unterschieden zwischen HTML und XHTML gefunden, aber keinen Hinweis darauf, was man jetzt besser verwenden sollte.
Bestimmt gabe es hier schon Diskussionen. Mit welchem Ergebnis?
Über Google habe ich mehrere (ältere) Hinweise gefunden, dass der IE mit XHTML Probleme hat. Ist dies Geschichte?

[suit]

Ich habe in Selfhtml ein Kapitel zu den Unterschieden zwischen HTML und XHTML gefunden, aber keinen Hinweis darauf, was man jetzt besser verwenden sollte.
Bestimmt gabe es hier schon Diskussionen. Mit welchem Ergebnis?

solange du das ganze als text/html verschickst, ist es ansich egal - mit xhtml hast du in zukunft aber mehr freude

Über Google habe ich mehrere (ältere) Hinweise gefunden, dass der IE mit XHTML Probleme hat. Ist dies Geschichte?

mit xhtml hat er keine probleme, nur mit application/xhtml-xml oder application/xml statt text/html als mime-type

[Cybaer]

Hi,

solange du das ganze als text/html verschickst, ist es ansich egal - mit xhtml hast du in zukunft aber mehr freude

Z.B. indem man (ggf. sogar wirklich) "Valides XHTML 1.0" codet, und dann irgendwann nach Jahren (wenn es an IE nur noch IE 9 aufwärts geben wird) feststellt, daß die Seite nicht funktioniert, wenn man sie als XHTML auch ausliefert?

IMHO: Wer Zukunftssicherheit haben möchte, der arbeitet mit XML und erzeugt daraus dann HTML oder XHTML, oder was auch immer gerade ansteht ...

mit xhtml hat er keine probleme, nur mit application/xhtml-xml oder application/xml statt text/html als mime-type

Stimmt, im Verarbeiten von fehlerhaftem HTML war und ist der IE wirklich Spitze. XHTML kann er hingegen (bis auf weiteres) nicht ...

Gruß, Cybaer

[suit]

IMHO: Wer Zukunftssicherheit haben möchte, der arbeitet mit XML und erzeugt daraus dann HTML oder XHTML, oder was auch immer gerade ansteht ...

wer zukunftssicherheit haben möchte arbeitet mit einem weitestgehend medienneutralen datenformat und erzeugt sich daraus, was er will - html, xml, latex, pdf oder meinetwegen pngs - völlig wurscht ;)

[Cybaer]

Hi,

Ich habe in Selfhtml ein Kapitel zu den Unterschieden zwischen HTML und XHTML gefunden,

Wobei man verdeutlichen sollte, daß sich diese Unterschiede auch auf JS auswirken (HTML: Tagname immer groß, XHTML: Tagname immer klein).

aber keinen Hinweis darauf, was man jetzt besser verwenden sollte.

Prinzipiell: Wenn Du XHTML ausliefern möchtest (warum auch immer), dann nimm XHTML. Wenn Du HTML ausliefern möchtest (warum auch immer), dann nimm HTML. Wenn Du ein "gutes" Datenformat brauchst, dann nimm XML - und wandele es in HTML oder XHTML um.

Bisherige Diskussionen (so es sie gegeben hat), sind allerdings noch davon ausgegangen, daß a) XHTML-Coder gezwungen sind, nicht so schludrig zu coden, wie es  viele HTML-Coder tun, und b) daß HTML von XHTML abgelöst werden wird (XHTML 1.0 als Übergang, danach dann XHTML 1.1 bzw. mit 2 der wirklich große Bruch).

Beides hat sich als unrealistisch bzw. falsch herausgestellt.

Ad 1) I.d.R. werden XHTML-Dokumente nicht als XHTML ausgeliefert, sondern als (im Grunde genommen fehlerhaftes) HTML (mangels ausreichender Browserunterstützung). Deswegen wird der Autor auch nicht "gezwungen" sauberen Code zu schreiben. Er kann rumsauen, wie halt in HTML auch - nur steht jetzt XHTML drauf. Wer allerdings (sinnvollerweise) "sauberen Code" schreiben möchte (und sich ggf. sogar an die offiziellen Standards halten möchte), kann dies allerdings auch mit HTML. Dafür braucht es kein XHTML.

Ad 2) Nachfolger von XHTML 1.0 wurde (bis auf weiteres) nicht XHTML 1.1, sondern (X)HTML 5. Das W3C konnte sich mit ihren theoretischen Elfenbeinvorstellungen und dem jahrelangen vor sich hin wursteln nicht gegen Industrie/Programmierer/Anwender durchsetzen. Ergebnis ist ein neuer HTML-Standard, den man (natürlich) auch in XHTML-Notation schreiben kann (wobei auch hier gilt: JS reagiert in beiden Notationen unterschiedlich).

Über Google habe ich mehrere (ältere) Hinweise gefunden, dass der IE mit XHTML Probleme hat. Ist dies Geschichte?

Nein. Selbst die nächste Version (IE 8) wird, wenn nicht noch ein groooooßes Wunder geschieht, XHTML nicht beherrschen.

D.h., zumindest für die IEs wird man auf unbestimmte Zeit kein XHTML ausliefern können, sondern muß HTML ausliefern.

Lesetip: http://hixie.ch/advocacy/xhtml

Gruß, Cybaer

[molily]

Hallo,

Bisherige Diskussionen (so es sie gegeben hat), sind allerdings noch davon ausgegangen, daß a) XHTML-Coder gezwungen sind, nicht so schludrig zu coden

Wer behauptet das denn?
Also die »bisherige Diskussion« verfolge ich seit Jahren und habe ich immer Einspruch gegen solche Mythen. Das klingt eher nach straw man argument.

I.d.R. werden XHTML-Dokumente nicht als XHTML ausgeliefert ... Deswegen wird der Autor auch nicht "gezwungen" sauberen Code zu schreiben. Er kann rumsauen, wie halt in HTML auch - nur steht jetzt XHTML drauf.

Ja, aber was hat das miteinander zu tun? Selbst wenn XHTML-Dokument als solche ausgeliefert werden würden: Lediglich die Wohlgeformtheit wäre eine Voraussetzung. Wohlgeformter Code kann auch Müllcode sein. Wohlgeformtheit ist natürlich ein wichtiger Teil von sauberem Code und daran krankt es bei dem meisten Code schon.

Wer allerdings (sinnvollerweise) "sauberen Code" schreiben möchte (und sich ggf. sogar an die offiziellen Standards halten möchte), kann dies allerdings auch mit HTML. Dafür braucht es kein XHTML.

Mit XHTML hast du die Möglichkeit, den Code auf Wohlgeformtheit und gegen ein rigides Schema zu validieren. Damit ist automatisierte Fehlersuchung und Qualitätssicherung auf hohem Niveau möglich.

Mit HTML hast du die Möglichkeit, den Code gegen eine angepasste SGML-Deklaration und eine angepasste DTD zu validieren. Damit kann man auch relativ rigide Anforderungen prüfen - man kommt aber prinzipiell nicht an XHTML-Schema-Validierung heran. Zudem bringt die XHTML-Welt all diese Tools schon mit. Bei HTML/SGML muss man selbst basteln (haben wir z.B. lange bei SELFHTML gemacht, bevor wir auf ein eigenes XML-Format umgestiegen sind).

Mathias

[Cybaer]

Hi,

Bisherige Diskussionen (so es sie gegeben hat), sind allerdings noch davon ausgegangen, daß a) XHTML-Coder gezwungen sind, nicht so schludrig zu coden
Wer behauptet das denn?
Also die »bisherige Diskussion« verfolge ich seit Jahren und habe ich immer Einspruch gegen solche Mythen. Das klingt eher nach straw man argument.

Gegen welchen Mythos erhebst Du Einspruch? Gegen den Mythos, "XHTML zwinge zu saubererem Coden" oder gegen den Mythos, "XHTML-Fans preisen als ein Vorteil an, daß man weniger schludrig coden darf"? :)

Mir ist jetzt allerdings auch gerade nicht klar, wie Du das mit dem Strohmann-Argument meinst.

Ich meine (jetzt mal nur für sich genommen und z.B. Browserproblematik u.s.w. außen vor gelassen!):

• Sauberes HTML ist gut, sauberes XHTML ist besser
• Man sollte eh wissen, was man tut (OK, xx% der Webseitenautoren wissen es vielleicht/offensichtlich nicht)
• XHTML legt strengere Maßstäbe an (Groß-/Kleinschreibung, keine offenen Elemente, generell: Wohlgeformtheit, und noch einiges mehr)
• Wer sich wirklich mit HTML beschäftigt, wird sauberen Code schreiben. Wer es nicht tut, wird dadurch nicht sterben (wg. der Fehlertoleranz der HTML-Browser)
• Wer sich wirklich mit XHTML beschäftigt, wird sauberen Code schreiben. Wer es nicht tut, wird dadurch nicht sofort sterben (wg. der Fehlertoleranz der HTML-Browser, da XHTML üblicherweise als HTML ausgeliefert wird). Aber er wird sich in ein paar Jahren vielleicht "wundern", warum sein "XHTML" gar keines ist, oder, warum das JS in seinem XHTML "plötzlich" nIcht mehr funktioniert.

Wohlgeformtheit ist natürlich ein wichtiger Teil von sauberem Code und daran krankt es bei dem meisten Code schon.

In der Tat.

Gruß, Cybaer

[molily]

Hallo,

Gegen welchen Mythos erhebst Du Einspruch?

Gegen den, dass »sauberer Code« überhaupt anderes bedeuten könnte als Wohlgeformtheit. (Und, wie du sagst, ein Zwang existiert praktisch nicht.)

• Wer sich wirklich mit HTML beschäftigt, wird sauberen Code schreiben.

Klar, wer HTML nicht beherrscht, wird auch mit XHTML nicht besser zurecht kommen, aber trotzdem schätze ich als Profi die maschinell überprüfbare Strenge von XHTML, weil ich genauso dumme Fehler mache. Solche Fehler automatisiert in HTML zu finden ist ungemein schwieriger.

• Wer sich wirklich mit XHTML beschäftigt, wird sauberen Code schreiben. Wer es nicht tut, wird dadurch nicht sofort sterben (wg. der Fehlertoleranz der HTML-Browser, da XHTML üblicherweise als HTML ausgeliefert wird). Aber er wird sich in ein paar Jahren vielleicht "wundern", warum sein "XHTML" gar keines ist, oder, warum das JS in seinem XHTML "plötzlich" nIcht mehr funktioniert.

Nunja - diese »Sie werden sich irgendwann wundern und XHTML verfluchen«-Prognose, die auf Hixie einst als Argumente anbrachte, macht zwei Annahmen, die ich nicht für gegeben halte: Irgendwer verspricht Webautoren das Blaue vom Himmel: XHTML könnt ihr mit allen möglichen XML-Tools verarbeiten und daraus viele Vorteile ziehen! Gleichzeitig wird verschwiegen, dass die Verarbeitung als echtes XML anders abläuft als text/html-Tag-Soup und man sich nicht auf Tag-Soup-Parsing ausruhen will, sondern immer wieder mit XML-Prozessoren prüfen sollte.

Eine solche Täuschung sehe ich eigentlich nicht - die gab es vielleicht mal vereinzelt. Und wenn, die Problematik lässt sich ganz einfach auflösen, indem man immer wieder betont, was es mit XHTML auf sich hat - zeitgemäße Dokumentationen machen das m.E. auch.

Mathias

[molily]

Nunja - diese »Sie werden sich irgendwann wundern und XHTML verfluchen«-Prognose, die auf Hixie einst als Argumente anbrachte, macht zwei Annahmen, die ich nicht für gegeben halte: Irgendwer verspricht Webautoren das Blaue vom Himmel: XHTML könnt ihr mit allen möglichen XML-Tools verarbeiten und daraus viele Vorteile ziehen! Gleichzeitig wird verschwiegen, dass die Verarbeitung als echtes XML anders abläuft als text/html-Tag-Soup und man sich nicht auf Tag-Soup-Parsing ausruhen will, sondern immer wieder mit XML-Prozessoren prüfen sollte.

Jetzt nochmal auf deutsch:

Diese »Sie werden sich irgendwann wundern und XHTML verfluchen«-Prognose, die Hixie einst als Argument anführte, macht zwei Annahmen, die ich nicht für gegeben halte: Irgendwer verspricht Webautoren das Blaue vom Himmel: XHTML könnt ihr mit allen möglichen XML-Tools verarbeiten und daraus viele Vorteile ziehen! Gleichzeitig wird verschwiegen, dass die Verarbeitung als echtes XML anders abläuft als text/html-Tag-Soup und man sich nicht auf Tag-Soup-Parsing ausruhen darf, sondern immer wieder mit XML-Prozessoren prüfen sollte.

[Cybaer]

Hi,

Gegen welchen Mythos erhebst Du Einspruch?
Gegen den, dass »sauberer Code« überhaupt anderes bedeuten könnte als Wohlgeformtheit. (Und, wie du sagst, ein Zwang existiert praktisch nicht.)

Der Zwang kann sich jederzeit ergeben.

Für mich ist HTML-Gewurschtel unerwünscht aber (letztlich) harmlos, XHTML-Gewurschtel ist es auch, kann aber zur "Katastrophe" führen, weil Browser XHTML-Dokumente mal als HTML- mal als XHTML-Resourcen interpretieren (sowohl HTML-, als auch JS-Engine).

Klar, wer HTML nicht beherrscht, wird auch mit XHTML nicht besser zurecht kommen, aber trotzdem schätze ich als Profi die maschinell überprüfbare Strenge von XHTML, weil ich genauso dumme Fehler mache. Solche Fehler automatisiert in HTML zu finden ist ungemein schwieriger.

OK, kann ich nicht einschätzen. Fehler mache ich auch, aber mir reicht die Validation. Und ansonsten ist es eh egal, wenn das HTML aus XML generiert wird (da sollte schlicht die Engine richtig arbeiten).

Nunja - diese »Sie werden sich irgendwann wundern und XHTML verfluchen«-Prognose, die auf Hixie einst als Argumente anbrachte, macht zwei Annahmen, die ich nicht für gegeben halte:

Für mich ist sein Hauptargument: Jungs, eure Doks können später mal ganz anders behandelt werden, als ihr euch das jetzt vorstellt. Nämlich so, wie es sein sollte (aber noch nicht ist).

Er sagt *auch*: Kann man ja trotzdem machen (XHTML und dann als HTML ausliefern), wenn man genauestens weiß, was man macht. Aber man muß ja feststellen, daß die überwiegende Mehrheit (auch der "professionellen") Coder *nicht* weiß, was sie macht - was sie nicht daran hindert, XHTML zu nehmen und am besten noch Stolz wie Oskar ein "Valides XHTML 1.0 strict"-Bepperl auf die mediokren Seiten zu basteln. :->

Eine solche Täuschung sehe ich eigentlich nicht - die gab es vielleicht mal vereinzelt.

Immer noch in Webentwickler-Foren zu lesen.

OK, da kann man viel lesen ...

... auch meine Beiträge. >;->

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

aber keinen Hinweis darauf, was man jetzt besser verwenden sollte.

D.h., zumindest für die IEs wird man auf unbestimmte Zeit kein XHTML ausliefern können, sondern muß HTML ausliefern.

Die Frage des OP war nicht, ob HTML oder XHTML ausliefern; sondern ob HTML oder XHTML verwenden.

Für den Autor bietet XHTML klare Vorteile, damit sollte die Frage, welches besser zu verwenden sei, geklärt sein.

Es spricht nichts dagegen, HTML-kompatibles XHTML 1.0 als 'text/html' auszuliefern.

Lesetip: http://hixie.ch/advocacy/xhtml

Bitte nicht schon wieder dieser „sehr bekannte Artikel“, der „jedoch hauptsächlich dadurch besticht, dass er vor allem einseitig und irreführend ist.“ [Jendryschik]

Wie kannst du diesen Schmarrn immer noch als Lesetip anführen?

Lesetip: http://forum.de.selfhtml.org/archiv/2007/10/t160280/#m1042457 ff.

Live long and prosper,
Gunnar

[Cybaer]

Hi,

Bitte nicht schon wieder dieser „sehr bekannte Artikel“, der „jedoch hauptsächlich dadurch besticht, dass er vor allem einseitig und irreführend ist.“ [Jendryschik]

Ich teile Jendryschiks Meinung nicht!

Und ja: Der Artikel ist überspitzt - und das ist IMHO auch gut so.

Wer es weniger überspitzt haben möchte, der findet am Anfang von Hixies Text auch noch einen moderateren Artikel auf dem Blog der WebKit-Entwickler - und AFAIR dort auch noch weitere Links mit entsprechender Meinung.

Wie kannst du diesen Schmarrn immer noch als Lesetip anführen?

Du magst ihn für Schmarrn halten - ich nicht.

Und überhaupt: Von jemanden, der diesen hanebüchenen Subotnik-Artikel immer wieder verlinkt, hat hier überhaupt kein Mitspracherecht auf Verlinkungen ... :))

Lesetip: http://forum.de.selfhtml.org/archiv/2007/10/t160280/#m1042457 ff.

IMHO schlechter Tip.

Gruß, Cybaer

[molily]

Hallo,

Wer es weniger überspitzt haben möchte, der findet am Anfang von Hixies Text auch noch einen moderateren Artikel auf dem Blog der WebKit-Entwickler - und AFAIR dort auch noch weitere Links mit entsprechender Meinung.

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

»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«

Äh?! Logisch: mit stumpfen HTML-Validatoren kann man kein XHTML validieren. Man muss schon die richtigen Tools verwenden. Ein SGML-Parser wie der W3C Markup Validator, der ein bisschen aufgebohrt ist, um auch XML zu schlucken, ist natürlich ungeeignet für XML-Dokumente! In Zeiten, wo man XHTML-Dokumente problemlos gegen XML-Schemata validieren kann, juckt es einen wirklich nicht, dass konzeptionell auf SGML und SGML-artige Tag-Soup ausgerichtete Pseudo-Validatoren ablosen, wenn es um XML-Validierung geht.

Das ist nicht wirklich ein Nachteil von XHTML. Man muss nur irgendeinen validierenden XML-Prozessor kennen (als ob es da keine gäbe?!) oder besser gleich den XHTML Schema Validator.

and that you run the risk of subtle incompatibilities if your document is ever actually processed as XHTML.

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

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«.

what kind of benefits do you get if in the end it’s just treated as HTML tag soup?

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.

Dagegen die Argumente für HTML 4:

This way you’ll be using the best-tested mode of web browsers, won’t have to worry as much about weird compatibility issues, and will get the most benefit out of HTML-based toolchains.

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. Den letzten Teilsatz verstehe ich einfach nicht, die meisten »Toolchains« sind wohl XML-basiert, da HTML-Parsing außerhalb des Browsers überhaupt keine Rolle spielt. Wohl aber sind XML-Parsing, daran anschließend DOM, XSLT, XPath und Co. mittlerweile in jeder noch so dummen Entwicklungsumgebung möglich.

Mathias

[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

[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

[Cybaer]

Hi,

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.

Hmm, irgendwie habe ich das Gefühl, Du bist auf dem falschen Trip (oder die anderen sind es). =;-)

Der Artikel (oder Hixies oder die anderen verlinken) raten IMHO nur bedingt (ja, durchaus "auch") dazu.

*Du* kennst dich aus? Ja! Du möchtest XHTML coden= Mach es! Du möchtest es als text/html senden? Here you go!

Es geht aber *nicht* um die, die sich auskennen. Es geht (einzig!) um die, die sich (noch) nicht auskennen. Und offensichtlich läßt das "noch" verdammt lange auf sich warten - eben gerade noch eine nette, anspruchsvolle Applikation gesehen (also wirklich nichts von einem Laien/Newbie), deren Code als XHTML 1.0 strict ausgezeichnet ist (Validität habe ich nicht geprüft), und schön mit write() arbeitet.

Und alleine, daß man als Fortgeschrittener (erst recht aber als Anfänger), der die XHTML/HTML-Unterschiede nicht kennt (oder schlimmer: ignoriert und damit anderen ein schlechtes Vorbild ist), munter valide und funktionierende Webseiten in XHTML schreiben kann, die aber nicht mehr funktionieren, sobald man sie auch als XHTML ausliefert, ist für mich No-go - sorry. Und da hilft es m.V. gar nichts, daß Methode XY zukünftig vielleicht auch mal unter XHTML existieren wird (was ich nicht glaube - und: wozu auch? Ich arbeite z.B. auch unter HTML lieber mit DOM, als mit write()).

"Wir" brauchen write() nicht. "Wir" können hinter tagName ein toLowerCase() hängen. Wir können prefix oder namespaceURI abfragen, wes Syntax Kind das Dokument ist - und dann z.B. mit createElementNS() arbeiten, statt mit dem üblichen createElement().

*Das* ist der Hauptkritikpunt: Es gibt Unterschiede, und wer X nicht wirklich braucht, der sollte halt besser drauf verzichten - zumal Browserengines den HTML-Part mom. noch besser beherrschen.

Das Bewußtsein für die Problematik fehlt einfach! Und nicht nur, weil die Autoren ohne wirklich Grund zu XHTML greifen, nein, sie greifen oft überhaupt nicht. Der Programmierer ihrer Blog-Software/ihres Editor/... ist einfach nur der Meinung, daß XHTML gemacht werden soll (wobei der Programmierer oft schon selbst keinen Überblick hatte, wie es scheint).

Nicht mehr, nicht weniger!

Das ist ein Schwachpunkt im Artikel.

Ich glaube nach wie vor, daß da ein Mißverständnis zugrundliegt. Die Zielgruppe der
Artikel sind nicht die XHTML-Profis. Keiner der Bedenkenträger sieht die Welt untergehen, wenn man (notgedrungen und den Specs folgend), XHTML 1.0 codet und als HTML ausliefert, sofern der Client XHTML nicht beherrscht.

Es gibt da IMHO zwei Gattungen: Die einen sind Standardistas, denen invalider Code prinzipiell ein Greuel ist. XHTML ls HTML an XHTML-fähige Clients zu liefern, ist für die ein prinzipielles No-go. Die anderen machen sich mehr oder weniger darüber lustig, daß Newbies zu XHTML greifen, weil sie größten Wert auf Validität legen möchten (ansonsten aber von tuten und blasen keine Ahnung haben), aber gleichzeitig nichts dabei finden (falls sie es überhaut wissen), daß der Client statt dem supertoll-validen XHTML nur invalides HTML bekommt.

Nin, ich bin bekanntermaßen kein Standardista. Und auch wenn ich mich gerne über den 2. Punkt ebenfalls lustigmachen würde: Für mich ist nur ärgerlich, daß unbedachte Neu-XHTMLler in XHTML genauso rumsauen, wie sie es auch unter HTML tun/getan hätten, und daß sie aufgrund der JS- und sonstigen Problematik selbst dann kaum unter XHTML funktionierende "XHTML"-Webseiten schreiben, selbst wenn(!) sie ihren XHTML-Code erfolgreich validieren.

Und ich glaube kaum, daß dieser Mist von den XHTML-Vätern so gedacht, erwartet, geschweige denn gewollt worden ist ...

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).

Eben. Wozu auch. Das wäre Thema eines anderen Artikels, wie es sie (mehr oder leider i.d.R. eher weniger vollständig) an anderer Stelle gibt). Z.B.:
http://developer.mozilla.org/en/docs/Properly_Using_CSS_and_JavaScript_in_XHTML_Documents  (zumindest ein wenig hilfreich, aber bei weitem nicht so, wie es IMHO wünchesnwert wäre)
http://developer.mozilla.org/en/docs/DOM:element (wo dabei steht, in welchem Kontext eine Methode/Eigenschaft nutzbar ist)

Falls Du eine Quelle hast, wo wirklich alle diesbezügl. relevanten Informationen vollständig und korrekt zusammengefaßt werden: Bitte her mit dem URL!

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.

Es wird als Möglichkeit augelistet, aber es wird dem Leser nicht empfohlen. Für die Zielgruppe des Artikels, ist das IMHO keine Möglichkeit, aber jeder hat die Möglichkeit, sein Wissen zu erweitern, und sich aus dieser Zielgruppe herauszukatapultieren! :)

Seine Einwände dagegen sind banane, punkt.

Sind sie nicht, bzw. das, was Du besonders Banane findest, hast Du IMHO in den falschen Hals gekriegt (aber das schrieb ich ja schon).

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?

Gar nicht. Er (und andere) machen sich hier eher lustig über die Autoren, denen Validität (unreflektierterweise) heilig ist, aber unwissenderweise nichts dabei finden (ebenso unreflektierterweise) invaliden HTML-Code zu senden.

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,

Es gibt keines! (Hixies diesbezügl. Hinweis auf Nicht-SGML-konformen Code ist ja eher theoretischer Natur - mal von irgendeinem W3C-Testbrowser mal abgesehen.)

Selbst Hixie hat an anderer Stelle deutlich gesagt, daß er sich damit über die vermeintlichen Valid-Anbeter lustig gemacht hat!

Kann ich gut verstehen, ich habe mich ja schon selbst hier im Forum über die Valide-Bepperl-Kleber lustig gemacht ... :->

denn in der Praxis hat sich das tausendfach bewährt. Deshalb empfehlen Dokumentationen wie Jendryschiks XHTML als text/html.

Mit den Folgen, daß es nun im Web tausende XHTML-Seiten gibt, die als XHTML validieren, aber nicht funktionieren würden, wenn man sie als XHTML ausliefert. Das hat bestimmt niemand gewollt. Und es ist IMHO ein Grund, sich schwart zu ärgern. Selten, daß man ein so sinnvolles Projekt so gegen die Wand gefahren hat ...

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.

Ja ja ...

Es ist kein prinzipielles Problem, document.write auf XML umzuschreiben, genauso wie mittlerweile innerHTML im XML-Modus funktioniert.

Fein, dann können ja die Newbies mit dem Umstieg warten, bis das von dir genannte Szenario eingetreten ist.

Ich hingegen glaube nicht, daß die bestehenden JS-Unterschiede (s.o.) mal nivelliert werden.

Andernfalls wäre XHTML für mich sowas von unvollständig implementiert, daß man schon aus dem Grund Abstand davon nehmen sollte ...

Aber ich bezog mich ohnehin nur auf Stachowiaks Aussage, es gäbe nur für HTML ausgereifte Toolchains.

Wo steht den "nur"? Das ist doch eine Erfindung von dir!

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.

Vielleicht sollte man auch Tools erst nutzen, nachdem sie ein gewisse Reife erlangt haben? Zumindest im geschätlichen Umfeld. Was man als Hobby bettreibt, ist jedem seine eigene Sache ...

Wer bist Du, das besser zu wissen, als ein Safari-Entwickler? Der Safari-Chefentwickler?
Jemand, der Autoritätsargumente nicht gelten lässt,

Schön! :-))

sondern gefälligst eine technische Referenz haben will, die Abweichungen und Probleme dokumentiert.

Die dann von wem gelesen wird? Den Fachleuten. Nicht von demjenigen, der sich seinen XHTML-Head von einer anderen Seite kopiert.

Die wirken dann als self-fulfilling prophecy - da kann man auch gleich die XHTML-Unterstützung abschalten.

Gib ihnen die Zeit zum Entwickeln. Und: Klar, man entwickelt eher für die 99,99% HTML-User, als für die 0,01% XHTML-User.

Du möchtest den Schwerpunkt ihrer Tätigkeiten vielleicht umlenken, ich denke: Leute, wartet ab, bis wir weiter sind.

Daß das W3C an der Realität (auch der Browserprogrammierer) vorbeiagiert (hat), ist ja keine neue Erkenntnis ...

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.

Ja, ich habe ja auch überhaupt kein Problem mit dieser Einstellung. Denn ich gehe dennoch davon aus, daß deine XHTML-Dokumente auch dann funktionieren, wenn sie als XHTML ausgeliefert würden. Wenn das anders wäre, damit hätte ich ein Problem (also: prinzipiell natürlich - was gehen mich deine Seiten an?! =;-)).

Ich habe prinzipiell auch immer ein Problem, wenn Leute Dinge nicht hinterfragen, und einfach gedankenlos machen.

Aber so ist das Agieren der überwiegenden Mehrheit der (X)HTML-Coder.

Trotzdem schmeiße ich mich deswegen natürlich nicht vor den nächsten Zug ... =;->

Gruß, Cybaer

[molily]

Hallo,

Die wirken dann als self-fulfilling prophecy - da kann man auch gleich die XHTML-Unterstützung abschalten.

Gib ihnen die Zeit zum Entwickeln. Und: Klar, man entwickelt eher für die 99,99% HTML-User, als für die 0,01% XHTML-User.

Du möchtest den Schwerpunkt ihrer Tätigkeiten vielleicht umlenken, ich denke: Leute, wartet ab, bis wir weiter sind.

Ach, ich will überhaupt nichts umlenken. Ich beleuchte nur die Hintergründe der aktuellen Situation hinsichtlich XHTML-Browserimplementierung.

Manche Autoren (sagen wir mal 99,99%) widmen sich nun einmal ausschließlich der Tag-Soup und haben für XML und XHTML wenig übrig. Sollen sie meinetwegen tun, aber es ist gerade wegen des Verhältnisses sehr billig, Artikel wie Stachowiaks zu schreiben und damit faktisch nur einen Beitrag dazu leisten, XHTML auf dem Müllhaufen der Geschichte zu entsorgen. Gerade als Browserprogrammierer ist es noch billiger, sich darauf auszuruhen, ständig »Die Unterstützung ist schlecht, benutzt es nicht!« zu rufen. Da sind mir Microsofts leere Versprechungen noch lieber. ;)

Leute wie Hixie haben die praktischen Probleme von XHTML schon vor Jahren kompakt *beschrieben*. Stachowiaks Artikel wiederholt, was 2001/2002 allgemein in der XHTML-affinen Community bekannt wurde. Leider haben diese Artikel keinen Deut zur *Lösung* beigetragen! Ihr letztendlicher Nutzen ist daher bloß, den XHTML-Tisch endlich abzuräumen, schließlich hat man sich mittlerweile komplett HTML 5 verschrieben und träumt ganz andere Träume.

Dann gibt es Leute (sagen wir mal 0,01%), die bleiben nicht bei der Problembeschreibung stehen, sondern versuchen ausgehend davon die Lage zu verbessern. Z.B. Christoph Schneegans schreibt XHTML-FAQs und programmiert unverzichtbare Tools wie einen X(HT)ML Schema Validator und einen XHTML-Proxy. Das ist mir tausendmal mehr wert, als seit 2002 gebetsmühlenartig zu wiederholen: Ach, vergesst XHTML, denn die Lage ist so schlimm, und downgradet auf HTML 4.

Mathias

[Cybaer]

Hi,

es ist gerade wegen des Verhältnisses sehr billig, Artikel wie Stachowiaks zu schreiben und damit faktisch nur einen Beitrag dazu leisten, XHTML auf dem Müllhaufen der Geschichte zu entsorgen.

Warum *wiederholst* Du immer wieder deine abstrusen Auffassungen bezügl. der Texte?

Zum (gefühlten) Hundertausendstenmal: *Niemand* will XHTML entsorgen - auch niemand von den "besorgten" Artikelschreibern.

*Niemand* hat etwas gegen den bewußten Umgang mit XHTML, die "Bedenkenträger" haben etwas gegen den unbewußten Umgang mit XHTML - inkl. der Fehler die sich dadurch ergeben, inkl. der "Verhunzung" eines Formates, das auch angetreten war, die "Verhunzung" (mindestens) zu reduzieren.

Da wird halt ein Format mißbraucht, für das die Entwickler das nicht vorgesehen haben. Oder, um mit einem Moz-Entwickler zu sprechen: "(...) the failure of popular web browsers to properly support XHTML combined with a lack of understanding by web authors of the fundamental differences between HTML 4 and XHTML, is creating a growing problem on the web today."

Damit ist nicht gemeint, XHTML sei schlecht. Damit ist der IE gemeint, und die User, die XHTML unbewußt einsetzen (*z.B.* weil die Dreamweaver-Programmierer in ihrer Allwissenheit als Standard XHTML erzeugen - als wenn der gemeine DW-Nutzer Ahnung von (X)HTML hätte ...), ganz so, wie "Tag-Soup-HTML mit einer ein bißchen anderen Syntax".

Leute wie Hixie haben die praktischen Probleme von XHTML schon vor Jahren kompakt *beschrieben*. Stachowiaks Artikel wiederholt, was 2001/2002 allgemein in der XHTML-affinen Community bekannt wurde. Leider haben diese Artikel keinen Deut zur *Lösung* beigetragen!

Ja, vielleicht schwebt dir ein totalitärer Staat vor, der die Webbürger dazu zwingt, Validatoren zu benutzen? >;->

Ich denke, der Nutzen solcher Texte ist, daß die, die wenigstens generell was zur Materie lesen, auf das Problem (s.o.) aufmerksam werden, und sich mit unreflektierten Empfehlungen von XHTML an noch "Bemitleidenswertere" (z.B. in Foren) zurückhalten, bzw. wenigstens gleichzeitig die Problematik *explizit* zu verdeutlichen.

Ihr letztendlicher Nutzen ist daher bloß, den XHTML-Tisch endlich abzuräumen, schließlich hat man sich mittlerweile komplett HTML 5 verschrieben und träumt ganz andere Träume.

Warum ist die Notation von HTML 5 in XHTML dann möglich, wenn man XHTML abräumen möchte? Das ist doch Bullshit ...

Wenn die Browserhersteller XHTML abräumen wollten, können sie die Entwicklung der XHTML-Engines (mindestens) einstellen, und sagen: Zukünftig supporten wir nur noch HTML 5 ff. XHTML ist fr uns gestorben. Sagt keiner. Denkt auch keiner. Oder zumindest: Es schreibt keiner.

Z.B. Christoph Schneegans schreibt XHTML-FAQs und programmiert unverzichtbare Tools wie einen X(HT)ML Schema Validator und einen XHTML-Proxy.

Browserprogrammierer entwickeln Browser - und warnen vor unsachgemäßem Einsatz. Das ist ihr Job.

Andere machen andere Dinge. Jeder wie er's mag und Zeit hat.

Wer den W3C-Validator, wenn überhaupt, nur vom Hörensagen kennt, der wird den Schema-Validator erst recht nicht kennen - geschweige denn nutzen. Du schreibst IMHO komplett an der Problematik vorbei ...

Das ist mir tausendmal mehr wert, als seit 2002 gebetsmühlenartig zu wiederholen:

Wenn hier einer gebetsmühlenartig Unsinn wiederholt, dann bist das Du mit deinem stetig wiederholtem "XHTML soll zugunsten von HTML abgeschafft werden". Sorry, aber  das muß man so drastisch schreiben ...

Gruß, Cybaer

[Tim Tepaße]

Hallo Cybaer,

Ad 2) Nachfolger von XHTML 1.0 wurde (bis auf weiteres) nicht XHTML 1.1, sondern (X)HTML 5. Das W3C konnte sich mit ihren theoretischen Elfenbeinvorstellungen und dem jahrelangen vor sich hin wursteln nicht gegen Industrie/Programmierer/Anwender durchsetzen.

Wenn Du mit dem Elfenbein die fehlenden Abwärtskompablität bezeichnest, dürfte Dir wohl jeder zustimmen. Oder gibt es anderes, was Du an XHTML 2 als elfenbeinig bezeichnest? Lässt man ersteren Aspekt weg, finde ich XHTML 2 gar nicht so schlimm; einige Möglichkeiten daraus vermisse ich immer noch in (X)HTML 5.

Tim

[Cybaer]

Hi,

Wenn Du mit dem Elfenbein die fehlenden Abwärtskompablität bezeichnest, dürfte Dir wohl jeder zustimmen.

Ja, die meine ich. Aber nicht nur.

Oder gibt es anderes, was Du an XHTML 2 als elfenbeinig bezeichnest? Lässt man ersteren Aspekt weg, finde ich XHTML 2 gar nicht so schlimm; einige Möglichkeiten daraus vermisse ich immer noch in (X)HTML 5.

Ich möchte nicht mißverstanden werden: Ich finde XHTML gut! Und die Möglichkeiten von XHTML 2 finde ich suuuuuper! Ich meine: Da müssen doch jedem Nerd die Augen aufblitzen! 8-))

Aber ein einfaches (auch bei weitem nicht perfektes) aber extrem erfolgreiches System für IT-Laien (als das HTML ja zumindest mal angetreten war), ersetzen zu wollen durch eine Super-Duper-Nerd-Phantasie, eine riesige, inkompatible, hochkomplexe eierlegende Wollmilchsau, ist halt bei aller Liebe dennoch nicht meine Vorstellung für ein erfolgreiches (auch und gerade im Sinne von userfreundlich oder "bürgernah") Web der Zukunft ...

... WYSIWYG-Editoren hin, Homepage-Maker her.

Gruß, Cybaer

PS: Die Frage, ob dieses Ansinnen jemals auch nur im Ansatz realistisch war, oder ob WHATWG & HTML 5 eine "zwangsläufige" "Revolution" war, weil es immer noch genug Menschen mit Realismus gibt (oder das zumindest so empfinden >;->), finde ich in diesem Zusammenhang übrigens auch interessant. :)

[suit]

Ich möchte nicht mißverstanden werden: Ich finde XHTML gut! Und die Möglichkeiten von XHTML 2 finde ich suuuuuper! Ich meine: Da müssen doch jedem Nerd die Augen aufblitzen! 8-))

naja, teilweise ist xhtml 2 schon sinnlos kompliziert

<p><l>zeile</l><l>zeile</l></p> ist schon etwas unpraktisch - zwar lassen sich auch so einzelne zeilen vor und nach dem umbruch, am anfang und am ende usw formatieren, aber etwas übertrieben ist das schon

warum man <separator /> nicht einfach <sep /> genannt hat verstehe ich zb auch nicht

[Gunnar Bittersmann]

@@suit:

<p><l>zeile</l><l>zeile</l></p> ist schon etwas unpraktisch - zwar lassen sich auch so einzelne zeilen vor und nach dem umbruch, am anfang und am ende usw formatieren, aber etwas übertrieben ist das schon

Finde ich nicht. So steht der Text da, wo er hingehört: _in_ einem Element. Und nicht ein Element (br), was „zwischen den Zeilen“ steht.

Wenn du Lyrik (Thanks, Bruce) so formatieren willst:

The screen door slams
Mary's dress waves
Like a vision she dances
  across the porch
As the radio plays
Roy Orbison singing for
  the lonely
Hey that's me and I want
  you only
Don't turn me home again
I just can't face myself
  alone again

(also wenn eine Textzeile nicht in eine Bildschirmzeile passt, soll nach dem durch die Box bedingten Umbruch eingerückt werden; bei einer neuen Textzeile soll wieder vorn begonnen werden), dann ist das mit diesem Markup

<p>  
  <l>The screen door slams</l>  
  <l>Mary's dress waves</l>  
  <l>Like a vision she dances across the porch</l>  
  <l>As the radio plays</l>  
  <l>Roy Orbison singing for the lonely</l>  
  <l>Hey that's me and I want you only</l>  
  <l>Don't turn me home again</l>  
  <l>I just can't face myself alone again</l>  
</p>

kein Problem:

p { margin-left: 1em }  
l { text-indent: -1em }

Versuch das mal für

<p>  
  The screen door slams<br />  
  Mary's dress waves<br />  
  Like a vision she dances across the porch<br />  
  As the radio plays<br />  
  Roy Orbison singing for the lonely<br />  
  Hey that's me and I want you only<br />  
  Don't turn me home again<br />  
  I just can't face myself alone again  
</p>

hinzubekommen!

warum man <separator /> nicht einfach <sep /> genannt hat verstehe ich zb auch nicht

Weil 'separator' besser verständlich ist als 'sep'?

Live long and prosper,
Gunnar

[Tim Tepaße]

Hallo Cybaer,

Wenn Du mit dem Elfenbein die fehlenden Abwärtskompablität bezeichnest, dürfte Dir wohl jeder zustimmen.
Ja, die meine ich. Aber nicht nur.

Deswegen frage ich ja nach, wie von mir gewohnt immer nach Details. ;)

... durch eine Super-Duper-Nerd-Phantasie, eine riesige, inkompatible, hochkomplexe eierlegende Wollmilchsau, ...

Denn: Lässt man die komplexeren Dinge der Erweiterung XForms weg, scheint doch der Kernsprachbestand von XHTML 2 sehr überschaubar zu sein, gut von Laien zu verstehen und sogar bestimmte Fragen dieser zu beantworten (»Was soll das heißen, ich kann nicht überall einen Link machen?«). Deswegen suche ich immer noch die Riesigkeit, die Nerdigkeit, die Hochkomplexheit, der Wahnsinn, der angeblich nur noch von Akademikern in ihren Elfenbeintürmen zu verstehen ist. Deswegen frag ich dann nach ... und kriege schon wieder keine Bespiele hypothetischen XHTML 2 Codes, der nach der Meinung des gefragten hochkomplizierter sein soll als es muß.

Oder liege ich falsch in meiner Einschätzung, dass das Problem an XHTML 2 weniger die Elemente, sondern die nicht vorhandene Kompabilität zum derzeitigen Web ist. Wenn ja: Warum? Erzählt es mir doch mal.

PS: Die Frage, ob dieses Ansinnen jemals auch nur im Ansatz realistisch war, oder ob WHATWG & HTML 5 eine "zwangsläufige" "Revolution" war, weil es immer noch genug Menschen mit Realismus gibt (oder das zumindest so empfinden >;->), finde ich in diesem Zusammenhang übrigens auch interessant. :)

Ich glaube, es war seit ... sagenwirmal 2002 durchaus absehbar war, dass XML im Browser-Web nicht so erfolgreich war, ab 2004, dass sich eine Gegenbewegung, auch und gerade unter Standardistas und Browser-Herstellern bildete. Zwangsläufig ist das nur in dem Zusammenhang, dass das reale Web eben ein ziemliches Beharrungsvermögen hat und dass auf dem Markplatz der Ideen größere Mitspieler dann durch Untätigkeit einzelner, Verbissenheit anderer und notwendigen Pragmatismus Dritter dadurch dann ein Trend entstanden ist. Zwingende, alternativlose Zwangsläufigkeit sehe ich da nicht, sehe ich eigentlich nie. HTML 3.2 & 4.0 kamen über HTML 3.0, DOM-DHTML über Netscapes Layerei, Web Standards über Tag Soup; alles keine Zwangsläufigkeiten. Die Hose, der Weg der Zeit gabelt sich eigentlich immer und manchmal münden vermeintliche Irrwege wieder im breiten Trampelpfad – zumindest wünsche ich mir das für einige XHTML 2 Ideen, die gefälligst in HTML 5 einfließen sollten.

Tim

[Cybaer]

Hi,

Denn: Lässt man die komplexeren Dinge der Erweiterung XForms weg, scheint doch der Kernsprachbestand von XHTML 2 sehr überschaubar zu sein,

Absolut. Ich sehe allerdings nicht nur den "Kernbestand". Ich beziehe da letztlich auch solche Sachen mit ein wie SVG oder MathML - halt alles im XML-Umfeld, aber nicht nur. Denn mit den Möglichkeiten schwindet, (notwendige) Modularisierung hin oder her, IMHO auch die Übersichtlichkeit.

Ich teile z.B. auch Crockfords Meinung: CSS ist ein Desaster. Man sollte es komplett wegschmeißen und was gescheites neues dafür machen. (sinngemäß)

Generell ärgert mich die Tendenz, die Möglichkeiten (die ich persönlich durchaus schätze) immer mehr aufzublasen und damit letztlich Einstieg und Arbeit für den Laien zu erschweren. Die psychische Schwelle für Einsteiger ist IMHO mittlerweile ziemlich hoch ("Das macht man in CSS!" "Oh, da muß ich mich dann auch noch einarbeiten." ...).

Oder liege ich falsch in meiner Einschätzung, dass das Problem an XHTML 2 weniger die Elemente, sondern die nicht vorhandene Kompabilität zum derzeitigen Web ist. Wenn ja: Warum? Erzählt es mir doch mal.

Im Prinzip habe ich kein Problem damit, 2 MLs parallel zu haben: "Einfaches" (X)HTML für jedermann, und modularisiertes XHTML 2ff. für die, die das brauchen (und nutzen können).

Ob das wirklich sinnvoll ist, weiß ich ehrlich gesagt selber nicht. Absolutes No-go für mich war jedoch, alles auf XHTML (2) zu setzen, und die HTML-Weiterentwicklung einfach einzustellen.

Die Erwartung, die man (zumindest früher) immer mal in Foren gelesen hat: "XHTML erlaubt schlanke Engines (jetzt mal das Wichtigste betrachtet), und den Moloch der HTML-Engines werden wir, weil nicht mehr benötigt, endlich loswerden.", diese Erwartung halte ich nicht für realistisch. Man *wird* HTML *nicht* so einfach "loswerden".

dass das reale Web eben ein ziemliches Beharrungsvermögen hat

Ja, so sind Menschen nunmal. :)

Die Hose, der Weg der Zeit gabelt sich eigentlich immer und manchmal münden vermeintliche Irrwege wieder im breiten Trampelpfad – zumindest wünsche ich mir das für einige XHTML 2 Ideen, die gefälligst in HTML 5 einfließen sollten.

ACK.

Was mich auch ein wenig stört, sind die immer wieder gerne verbreiteten Hypes. Laß sich doch neue Techniken (inkl. XHTML) einfach in Ruhe entwickeln (nebst Browserunterstützung und Authoring Tools). Das kommt schon irgendwann - oder eben auch nicht. Aber wenn es wirklich (breit) nutzbar vorhanden ist, *dann* mache ich mir Gedanken um eine produktive Nutzung ...

... sollen die Leute bis dahin doch statt gutem XHTML gutes HTML lernen. Ich glaube kaum, daß das so schlimm ist. =;-)

Den Ansatz: "Wir, die 'Early Adopters', 'überreden' als Meinungsmultiplikatoren die Leute zu XHTML, obwohl die Basis noch gar nicht reif ist, und wenn alle (Gut-)Menschen erstmal XHTML coden, ist HTML endlich weg!" hat mich noch nie überzeugt, und ich fand ihn schon immer jenseits jeder Realität ...

Gruß, Cybaer

[molily]

Hallo,

Laß sich doch neue Techniken (inkl. XHTML) einfach in Ruhe entwickeln (nebst Browserunterstützung und Authoring Tools). Das kommt schon irgendwann - oder eben auch nicht. Aber wenn es wirklich (breit) nutzbar vorhanden ist, *dann* mache ich mir Gedanken um eine produktive Nutzung ...

Es funktioniert doch genau anders herum. Techniken entwickeln sich nicht von selbst "einfach in Ruhe", sondern es bedarf einer einflussreichen Community, die ihre Entwicklung forciert. Ja, das sind meist Spezialisten. Entwickler von Browsern und Editoren reagieren stark auf diese Trends und ohne Lobbydruck stecken sie nur selten von sich aus Kapazitäten in untrendige Techniken.

Eine solche Lobby gab es z.B. mal kurze Zeit für XHTML, jetzt gibt es eher eine Gegenbewegung. Wenn sich im Laufe von XHTML 5 nicht noch etwas ergibt, ist "oder eben auch nicht" angesagt. Das ist alles. Das liegt aber an nichts anderem als Hypes und Trends, die sich abwechseln.

Den Ansatz: "Wir, die 'Early Adopters', 'überreden' als Meinungsmultiplikatoren die Leute zu XHTML, obwohl die Basis noch gar nicht reif ist

Wo niemand ist, der multipliziert und überredet, gibt es auch keine Basis, die irgendwie reif werden könnte. Das gilt für alle möglichen Techniken. Wenn z.B. SELFHTML seit 2001 XHTML 1 gefahren hätte, wäre die "Basis" einfach eine ganz andere gewesen, dann hätte man nicht heute immer wieder von Null anfangen müssen, wenn es um das Thema geht.

Mathias

[Cybaer]

Hi,

Laß sich doch neue Techniken (inkl. XHTML) einfach in Ruhe entwickeln (...), *dann* mache ich mir Gedanken um eine produktive Nutzung ...
Es funktioniert doch genau anders herum. Techniken entwickeln sich nicht von selbst "einfach in Ruhe", sondern es bedarf einer einflussreichen Community, die ihre Entwicklung forciert.

Oh je, da hast Du eine fundamental andere Auffassung von der Einführung neuer Produkte, als ich. Und ich finde sie nicht gut (mal gaaaanz vorsichtig formuliert)!

"Voll daneben" trifft es auch. ;->

Aber ich bin eben von Haus aus Kaufmann, und kein Techie-Fanatiker ... >;-)

Wo niemand ist, der multipliziert und überredet, gibt es auch keine Basis, die irgendwie reif werden könnte.

Neue Produkte sind erfolgreich, wenn sie auf einen Markt treffen, der dafür einen Bedarf hat. Existiert der Bedarf nicht, dann floppt das Produkt. Also muß der Hersteller versuchen, dafür Bedarf zu erzeugen. Das nennt man Marketing.

Ein gutes (im Sinne von "sinnvollem") Marketing wirbt also mit den Vorteilen, die das Produkt bietet (leistungsmäßig, preislich, und/oder emotional - also kein wirklicher, sondern ggf. nur ein gefühlter Vorteil). Schlechtes Marketing zeichnet sich durch übertriebene oder gar falsche Versprechen aus (oder indem es gravierende Nachteile verschweigt). Das erzeugt, früher oder später, unzufriedene Kunden, die zukünftig selbst dann nichts mehr mit dem Hersteller oder dem Produkt zu tun haben wollen, wenn das Produkt mal ausgereift und wirklich toll sein sollte (1&1 macht z.B. gerade vor, wie man eine eigentlich gute Firma/gutes Produkt durch schlechten Kundenservice "verbrennt" - jedenfalls wenn ich die c't-reifen Stories aus meinem Bekanntenkreis so höre).

Besteht ein Bedarf der bislang nicht durch ein Produkt gedeckt wird, so ist es natürlich Ziel, ein neues Produkt zu erschaffen, das diesen bereits vorhanden Bedarf deckt.

Ist ein Produkt ertmal erfolgreich und wird weiterentwickelt, werden damit ggf. auch neue Bedürfnisse gedeckt, sprich: der Markt wird ausgeweitet.

Gibt ist also Bedarf für XML? Klar! XML ist schon jenseits des Webs sehr erfolgreich (auch also Ablösung des bislang schon sehr erfolgreichen SGML). D.h., der Markt an z.B. XML-Tools ist bereits vorhanden und wird sukzessive weiter wachsen.

Gibt es also Bedarf für XHTML? Klar! Aus verschiedensten Gründen gibt es diesen Bedarf (Modularisierung & Verwertungskette wären zwei).

Gibt es Bedarf für den gemeinen HTML-Coder, unreflektiert auf XHTML umzusteigen? Nein! Im Gegenteil.

Muß man für XHTML also einen Bedarf erzeugen, um die Entwicklung zu gewährleisten? Nein. Da es Bedarf gibt, muß dieser nur befriedigt werden.

Muß man also einen künstlichen Bedarf erzeugen, und dabei bei der Zielgruppe falsche Erwartungen wecken, oder sie im unklaren lassen, über etwaige Negativfolgen ihrer Entscheidung (sofern sie sich überhaupt entscheiden, und nicht ihr Authoring-Tool die "Entscheidung" für sie trifft)? Nein.

Wenn man also diese Produkt unreflektiert preist für Leute, die dafür keinen Bedarf haben (und die Folgen weder abschätzen können, noch wollen), dann nennt man das nicht "einflußreiche Community", sondern "scheiß irreführende Werbung".

Das gilt für alle möglichen Techniken. Wenn z.B. SELFHTML seit 2001 XHTML 1 gefahren hätte, wäre die "Basis" einfach eine ganz andere gewesen, dann hätte man nicht heute immer wieder von Null anfangen müssen, wenn es um das Thema geht.

Was für eine Hybris. IMHO überschätzt Du die Relevanz dieser "einflußreichen Community" *bei weitem*! SELFHTML ist sicher wichtig, aber es findet nur ein gaaanz kleiner Teil der (zukünftigen oder aktuelle) Webautoren hier hin.

Abermillionen invalider HTML-Tag-Soup-Seiten und Seiten mit JS-Fehlern zeigen mehr als deutlich, daß an SELFHTML die Webwelt nicht genesen wird (selbst wenn man sich nur auf die deutschsprachige Webwelt beschränkt) ...

Und was XHTML angeht: Nach vielen Jahren XHTML wird das Format vom größten Browserhersteller selbst in der nächsten Browserversion immer noch nicht unterstützt werden.

Ich meine: Wie dumm kann man eine Produkteinführung eigentlich versemmeln? MS ist Mitglied beim W3C. Hat dort mal jemand bei MS angefragt: Sagt mal, können wir in absehbarer Zeit damit rechnen, daß der IE auch XHTML unterstützen wird?

Was wird MS geantwortet haben?
[ ] Nein!
[ ] Vielleicht.
[ ] Ja!
[x] Das entscheidet irgendwann unsere Rechtsabteilung
;-)

Also ich finde das Vorgehen des W3Cs ungefähr so clever wie ein Autohersteller, der ein neues Auto auf den Markt bringt, das den speziellen Sprit XFuel braucht. Wobei der Hersteller vorher nicht auf die Idee kommt, mal bei den Ölfirmen nachzufragen, ob sie XFuel auch an den Tankstellen anbieten werden.

Aber Gottseidank kann man auch Normalbenzin tanken - hilfsweise und man soll es nicht, aber das wissen die meisten potentiellen Käufer schon gar nicht.

Und wenn man (i.d.R. zwangsweise oder unbedacht aus Unwissenheit) dann Normalbenzin statt XFuel tankt, kann man damit zwar fahren (exakt so wie mit jedem anderen Auto auch), hat aber keine Vorteile dadurch. Stattdessen kann man im schlechtesten Fall irgendwann, wenn es nur noch XFuel gibt, feststellen, daß das ständige Verwenden von Normalbenzin den Motor so ruiniert hat, daß man nun den Motor erstmal (für viel Geld) reparieren, oder, aufgrund der vergangenen Zeit sind Ersatzteile nicht mehr zu bekommen, sogar einen neuen Wagen kaufen muß.

Tja, wenn solches Vorgehen deiner Meinung nach (und das der "Hotshots", die deinen Text als "hilfreich" bewertet haben) gut und sinnvoll und üblich ist: Bitte sehr.

Ich klatsch da hingegen nur einmal mit der Hand an die Stirn, und wende mich wichtigeren Dingen zu ...

... zumal ich ja ohnehin der Meinung bin, daß sich XHTML auf Dauer etablieren wird (mindestens parallel zu HTML). Was ihr betreibt ist Volkserdummung - bestenfalls.

Gruß, Cybaer

[molily]

Hallo,

Muß man für XHTML also einen Bedarf erzeugen, um die Entwicklung zu gewährleisten? Nein.

Ich weiß nicht, inwiefern dein allgemeines Modell von Bedarf und Angebot hier anwendbar ist. Genutzt werden können nur die Techniken, die zur Verfügung stehen. Wenn Browserhersteller zugeben, dass ihre Implementierung kacke ist und deshalb von der Technik abraten, dann wird sich nie eine Nutzung herausbilden können. Ob sie es dann tut, hängt eher weniger von Browserherstellern ab. Die schreiben wenn es hoch kommt Dokumentationen für ihre Techniken und können deren Anwendung im Kleinen forcieren. Aber dass z.B. Webdesign mit Webstandards verbreitet ist, liegt nicht daran, dass die Browser von sich aus stillschweigend Implementierungsfehler repariert haben. Da könntest du sagen, die Webstandards-Bewegung hat künstlich Bedarf nach CSS-Layout erzeugt, indem sie alle Webdesignern indoktriniert hat, auf Tabellenlayout und Presentational Markup zu verzichten.

IMHO überschätzt Du die Relevanz dieser "einflußreichen Community" *bei weitem*! SELFHTML ist sicher wichtig, aber es findet nur ein gaaanz kleiner Teil der (zukünftigen oder aktuelle) Webautoren hier hin.

Ist eigentlich egal, wie das realistischerweise einzuschätzen ist: SELFHTML war nur ein Beispiel einer großen Referenz, die eben recht wenig Aufklärung bietet. Natürlich wäre das nur eine Informationsquelle von tausenden, aber wenn es mehrere gäbe, die das Thema auf hohem Niveau beackern würden, wäre schon viel gewonnen. Ich sehe das ja bei einigen Artikeln, die ich geschrieben habe. Wenn man nach zentralen Begriffen sucht, sind das mitunter die einzigen deutschsprachigen Artikel dafür. Entsprechend gefragt sind sie und entsprechend werden sie verlinkt und gelesen.

Abermillionen invalider HTML-Tag-Soup-Seiten und Seiten mit JS-Fehlern zeigen mehr als deutlich, daß an SELFHTML die Webwelt nicht genesen wird (selbst wenn man sich nur auf die deutschsprachige Webwelt beschränkt) ...

Ich denke schon. SELFHTML legt im Vergleich zu Publikationen aus der Webstandards-Umgebung eher wenig Wert auf valides Markup und aufgeräumten Code. Da ist SELFHTML doch arg »neutral«.

MS ist Mitglied beim W3C. Hat dort mal jemand bei MS angefragt: Sagt mal, können wir in absehbarer Zeit damit rechnen, daß der IE auch XHTML unterstützen wird?

Ich weiß nicht ganz, worauf du hinauswillst. Der Browserhersteller kann natürlich legitimerweise »nein« antworten. Sollte das W3C ihm dann damit in den Ohren liegen? Als XHTML eingeführt wurde, lag die IE-Entwicklung brach, und seit sie wieder angelaufen ist, heißt es immer: Wenn die anderen schlimmen quadrillionen Bugs vom Tisch sind, dann werden wir eine XHTML schön und sauber implementieren. Was wirfst du dem W3C nun vor? Hat das W3C 1998 gefragt, ob jemand CSS 2 will? Besser so, dass sie nicht gefragt haben. ;)

Was ihr betreibt ist Volkserdummung - bestenfalls.

Was betreibe ich eigentlich? Wer ist denn ihr? :)

Mathias

[Cybaer]

Hi,

Wenn Browserhersteller zugeben, dass ihre Implementierung kacke ist und deshalb von der Technik abraten, dann wird sich nie eine Nutzung herausbilden können.

Versuch mich nicht auf diese Schiene zu ziehen - auch nicht von der "anderen" Seite! =;-)

Browserhersteller geben das nicht zu, sie raten ja nur von XHTML ab, wenn man die XFeatures nicht braucht. Wenn doch, dann sagt doch IMHO keiner: Nutzt das um Himmels willen nicht!

Und daß die XHTML-Engines noch unausgereifter sind, ist doch nur natürlich und liegt in der Natur der Sache - aber man kann sie nutzen.

Also: Wer's braucht, nutzt es. Wer's nutzt, findet Bugs (und meldet sie hoffentlich). Die Engines werden besser - und sind irgendwann auch nicht schlechter, als die HTML-Engines. Nur: Es dauert halt länger. Aber das ist IMHO besser, als ein überstürzter Wechsel ...

Da könntest du sagen, die Webstandards-Bewegung hat künstlich Bedarf nach CSS-Layout erzeugt, indem sie alle Webdesignern indoktriniert hat, auf Tabellenlayout und Presentational Markup zu verzichten.

Das hat aber auch noch sehr, sehr viele nicht erreicht ...

Und: Ich selbst code ja auch (oft) "Old-School" (als Fallback - und OK: ohne FONT) - und lege dann CSS drüber. Ich habe CSS trotzdem von Anfang an gerne verwendet, und erachte es als (prinzipiell) extrem sinnvoll. Ich glaube auch, um CSS käme man nur dann herum, wenn man das Presentational Markup sukzessive weiter ausgebaut hätte. Aber daß das unsinnig gewesen wäre, da dürften sich wohl (fast) alle einig sein ...

Wenn man nach zentralen Begriffen sucht, sind das mitunter die einzigen deutschsprachigen Artikel dafür. Entsprechend gefragt sind sie und entsprechend werden sie verlinkt und gelesen.

Ja, kann ich nachvollziehen - und finde ich gut. Aber *die* Einschränkung findet sich ja gleich am Anfang: "Wenn"! Daß viel zu wenige Leute suchen, sich informieren, *das* ist doch gerade das Problem! Wenn alle die es anginge suchen würden, dann würde ja auch eine einzige gute Quelle reichen.

Ich weiß nicht ganz, worauf du hinauswillst. Der Browserhersteller kann natürlich legitimerweise »nein« antworten. Sollte das W3C ihm dann damit in den Ohren liegen?

Vermutlich wäre das sinnlos. Aber wenn man etwas neues im Web startet, dann ist es IMHO *absolut zwingend*, den Mitspieler aktiv auf seiner Seite zu wissen, der (damals) einen Marktanteil von >90% besaß! Und wenn ich dieser Unterstützung nicht sicher sein kann, dann muß ich entweder mein Projekt verschieben, bis MS einigermaßen soweit ist, oder es anders angehen. Z.B. indem HTML weiterentwickle, und parallel dazu etwas neues mache, das aber HTML *nicht* ersetzt (jedenfalls nicht im Moment). Das hätte signalisiert: HTML wächst und gedeiht - habt Spaß daran. Und übrigens: Wer mehr braucht, hier komtm was ganz heißes. Noch nicht unbedingt für alle, aber in Intranets z.B. echt cool.

Und darauf aufbauend, wäre es möglich gewesen, HTML peu a peu abzulösen (MS hat ja durchaus ihre Meriten was XML angeht verdient - und sie hätten sich auch bezügl. XHTML nicht verschließen können, wenn z.B. Firmenkunden deswegen das System wechseln - das ist wohl auch die einzige Sprache, die MS versteht).

Was hat das W3C gemacht? Sinngemäß: HTML 4.01 ist die letzte HTML-Version, das machen wir jetzt in XHTML für den Übergang, und nachfolgend nur noch XHTML. Und das in einer Situation, in der die, auf die es ankommt (die Browserhersteller), weder bereit, noch willens waren, *diesen* "stricten" Kurs mitzugehen.

Das nenne ich entweder ein Kommunikationsdesaster, oder eine weltfremde Ignoranz, wie man sie wohl selten findet (kein Wunder: solches Handeln könnte ein Wirtschaftsunternehmen glatt in die Insolvenz führen).

Was ihr betreibt ist Volkserdummung - bestenfalls.
Was betreibe ich eigentlich?

"Volksergötzung"! ;-)

Wer ist denn ihr? :)

Alle, die anderen ein X für ein H vormachen. ;-)

(Ja, ja, Du gehörst da nicht (mehr?) zu! Sorry.)

Gruß, Cybaer

[Tim Tepaße]

Hallo,

Absolut. Ich sehe allerdings nicht nur den "Kernbestand". Ich beziehe da letztlich auch solche Sachen mit ein wie SVG oder MathML - halt alles im XML-Umfeld, aber nicht nur. Denn mit den Möglichkeiten schwindet, (notwendige) Modularisierung hin oder her, IMHO auch die Übersichtlichkeit.

Lustig. MathML & SVG sind sogar für die direkte Einbindung in HTML 5 vorgesehen. Auch in die nicht-XML HTML 5 Serialisierung; im Moment wird noch diskutiert, ob da lustiges Zeug passiert, wie im HTML-Algorithmus für Teilbäume einen XML-Parser zu benutzen. D.h. im Prinzip gehört das Vokabular von SVG und MathML zu HTML 5 und erweitert den schon sehr großen Sprachbestand von alten und neuen Elementen von HTML 5 noch mehr.

Ich teile z.B. auch Crockfords Meinung: CSS ist ein Desaster. Man sollte es komplett wegschmeißen und was gescheites neues dafür machen. (sinngemäß)

Und wieder brüllt ihr diese Meinung ohne Angabe von Detail-Argumenten. ;)

Crockford ist manchmal ... sehr ... beknackt von meiner Warte aus. Aber auch in der Sache: Was mich an CSS stört, ist die mangelnde Ausführung und der IE. Rumhypothesierendes CSS 3 ist sehr, sehr genial.

Generell ärgert mich die Tendenz, die Möglichkeiten (die ich persönlich durchaus schätze) immer mehr aufzublasen und damit letztlich Einstieg und Arbeit für den Laien zu erschweren.

Da bin ich auf der anderen Seite. Weil hinter jedem Aufblasen steht auch immer ein konkreter Problemfall. Nehmen wir mal Schriften in CSS. In der Glyph-Darstellung mancher Zeichen gibt es Variationen, z.B. bei Ziffern, in der Theorie gibt es die nämlich in metaphorischen Kleinbuchstaben (wie in Georgia, unten ausgerichtet) und in metaphorischen Großbuchstaben. Die eine Darstellung ist da passender, die andere ist dort passender. Moderne und gut ausgestattete Schriftarten unterstützten beide Varianten. Und Designer jammern dann, weil sie kommen in CSS nicht an die Entscheidung zwischen verschiedenen Glyphen und können dann nicht effektiv gestalten wie sie wollen. Ich halte das für einen sehr validen Wunsch - wenn das Web immer mehr Print ersetzt oder für Anzugträger ausgedruckt wird, warum sollte man sich mit weniger zufrieden geben?

Also wird die kommende Überarbeitung von CSS 3 Fonts vermutlich die Nutzung von OpenType-Features beinhalten. Entweder mit einer neuen Eigenschaft oder mit weiteren Stichwörtern für text-variant. Und wieder ist CSS wieder etwas mehr aufgeblasen. Aber es ist ein berechtigter Problemfall, es wird seit Jahren von der Designer-Front gefordert. So geht es vielem in CSS und HTML und XHTML und SVG. Es besteht Bedarf, der durchaus erfüllt werden sollte.

Die psychische Schwelle für Einsteiger ist IMHO mittlerweile ziemlich hoch ("Das macht man in CSS!" "Oh, da muß ich mich dann auch noch einarbeiten." ...).

Ja, wobei das eher ein pädagogisches Problem ist. IMHO sollte HTML & CSS immer als Einheit zusammen verflochten unterrichtet werden, nicht als seperate Techniken. Da leiden wir immer noch unter altlastigen Vorstellungen aus den 90ern.

Im Prinzip habe ich kein Problem damit, 2 MLs parallel zu haben: "Einfaches" (X)HTML für jedermann, und modularisiertes XHTML 2ff. für die, die das brauchen (und nutzen können).

„Einfaches HTML“ kann ja schon einfach bedeuten, erstmal nur den „Kernbestand“ von HTML & CSS zu unterrichten; erweiterte Features wie WebForms oder CSS Counter sollten dann auf einer weiteren Ebene erklärt werden. Der Anfänger muss nicht alles sofort wissen, es reicht erstmal, zu erklären, wie er seine Überschrift gold glänzend rechtsbündig rotiertend hinkriegt. Wieder ein pädagogisches Problem. Tatsächlich passiert das ja andauernd; einfaches Wissen (<h1><img /></h1>) kriegt man überall, erweiterte Techniken (sIFR) verstecken sich dann im Wilden Weiten Web in irgendwelchen Blogeinträgen, während zukünftige, noch bessere Möglichkeiten ( h1 { content: url(bla.svg), contents; } ) bislang nur in einem hypothetischen Raum existieren, in dem bislang nur ein paar Interessierte rumsurfen. Verschiedene Wissen-Level sind ein Bestandteil des Menschseins.

Was mich auch ein wenig stört, sind die immer wieder gerne verbreiteten Hypes.

Da bin ich eher molilyesk.

Tim

[Cybaer]

Hi,

im Moment wird noch diskutiert, ob da lustiges Zeug passiert, wie im HTML-Algorithmus für Teilbäume einen XML-Parser zu benutzen.

LOL - na dann freuen wir uns schonmal auf XQuery, XPath, XSL, ... für HTML 5. >;-))

Und wieder brüllt ihr diese Meinung ohne Angabe von Detail-Argumenten. ;)

Crockford ist manchmal ... sehr ... beknackt von meiner Warte aus.

Tja nun, wo kämen wir auch hin, wenn alle einer Meinung wären? =;-)

Ich würde auch nicht sagen: CSS ist Scheiße!, sondern eher: CSS ist gefühlte Scheiße! >;->

Schon in Ermangelung einer besseren Alternative.

Rumhypothesierendes CSS 3 ist sehr, sehr genial.

STOP! Der feuchte Nerd-Traum tropft ja schon aus meinem Monitor! =;-)

Da bin ich auf der anderen Seite. Weil hinter jedem Aufblasen steht auch immer ein konkreter Problemfall.

Ja, kann ich verstehen, sehe ich auch so.

Und ja: Natürlich bin ich da selbst in einem Dilemma: Als Nerd, der das auch gerne hätte und nutzen würde. Als Mensch, der sieht, daß andere da überfordert sind (da braucht's kein CSS 3 und XHTML 2.0, das sehe ich ja heute schon).

Wie kann man das Dilemma lösen? Ehrlich gesagt: Ich habe keine Vorstellung! :-(

Vielleicht wären da zwei auf Dauer parallel existierende Standards, fehlertolerantes HTML mit den notwendigsten Modulen von was-auch-immer, sowie wirklich strenges XHTML mit allem-wo-gibt das Sinnvollste, was man realistischerweise machen soll.

Ja, wobei das eher ein pädagogisches Problem ist. IMHO sollte HTML & CSS immer als Einheit zusammen verflochten unterrichtet werden, nicht als seperate Techniken. Da leiden wir immer noch unter altlastigen Vorstellungen aus den 90ern.

Tja, "pädagogisches Problem" ist gut. Nur: Wir haben also Schulen, die FRAMES, FONT & JS-DOM-0 unterrichten (wenn überhaupt), Schulungen, die sicherlich besser sind (wobei es halt auf den/die Vortragenden ankommen dürfte) und die Masse der "da lese ich mich jetzt mal ein"- oder "try & error"-Newbies.

Eines meiner Crockfordschen Lieblingszitate ist:
There are no good texts on JavaScript programming. Most of the people on the web who are producing JavaScript programs learned ist by copying really bad examples from bad books, bad websites, and bad tools.

Natürlich, wie immer - soll ja auch unterhaltend sein(!) -, überspitzt und nicht ganz zutreffend (wobei es für den Anfänger halt schwer ist, die Perlenträger unter den Austern im Web zu finden: der kann noch nicht mal die Miesmuscheln von perlenlosen Austern unterscheiden). Aber bei XHTML ist die Situation IMHO mittlerweile ähnlich ...

... leider, und so war das bestimmt nicht gedacht (und so hatte ich mir das auch nicht vorgestellt).

Verschiedene Wissen-Level sind ein Bestandteil des Menschseins.

Keine Frage. Es hat aber auch noch nie in der Geschichte der Menscheit ein Medium gegeben, über das sich alle Menschen austauschen können (und sollen).

Wie also mit den unterschiedlichen Leveln umgehen?

Egal wie, aber daß, was die letzten Jahre abgegangen ist (der Otto-Normal-Webcoderm der, ausgerechnet, XHTML unreflektiert und i.d.R. grob fehlerhaft verwendet), ist ein Zustand, der *unter allen Umständen* hätte vermieden werden *müssen* ...

... schon aus Liebe zu X(HT)ML. Und schlicht aus Gründen der Zukunftssicherheit.

Was mich auch ein wenig stört, sind die immer wieder gerne verbreiteten Hypes.
Da bin ich eher molilyesk.

:) Ja, da werde ich gleich noch einen passenden Kommentar zu ablassen! >;->

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

Tja nun, wo kämen wir auch hin, wenn alle einer Meinung wären? =;-)

Kommt drauf an, wessen Meinung. >;->

Und ja: Natürlich bin ich da selbst in einem Dilemma: Als Nerd, der das auch gerne hätte und nutzen würde. Als Mensch, der sieht, daß andere da überfordert sind (da braucht's kein CSS 3 und XHTML 2.0, das sehe ich ja heute schon).

Wie kann man das Dilemma lösen? Ehrlich gesagt: Ich habe keine Vorstellung! :-(

(X)HTML- und CSS-Quelltext ist „Nerds“ vorbehalten, die anderen benutzen Editierwerkzeuge oder CMS, welche ihrerseits vernünftigen XHTML-2.0- bzw. CSS3-Code generieren.

Ich sähe dann auch wenig Bedarf für HTML 5. Das mag Hixie & Co. tieftraurig stimmen; ich würde kaum eine Träne vergießen.

Eines meiner Crockfordschen Lieblingszitate ist:
There are no good texts on JavaScript programming. Most of the people on the web who are producing JavaScript programs learned ist by copying really bad examples from bad books, bad websites, and bad tools.

Damit meint er sowas wie '<script>' (ohne 'type'-Attribut)? ;->

Live long and prosper,
Gunnar

[suit]

(X)HTML- und CSS-Quelltext ist „Nerds“ vorbehalten, die anderen benutzen Editierwerkzeuge oder CMS, welche ihrerseits vernünftigen XHTML-2.0- bzw. CSS3-Code generieren.

mit editierwerkzeugen kann nur vernünftiger code generiert werden, wenn die leute damit umzugehen wissen - nichtmal wenn man jemandem einen editor gibt der dediziert "überschriften" erzeugen kann, werden diese genutzt - meistens wird ein normaler text fett und gross gemacht und die sache hat sich - ob das ein tinymce oder word ist, ist dabei egal

dreamweaver produziert prinzipiell halbwegs vernünftigen code, wenn man weiß damit umzugehen - nur der richtige umgang damit ist so kompliziert, dass man es gleich wieder per hand machen kann ;) - und wenn man den schnellen weg (zur dunklen seite der macht) wählt, kommt eben horror-code raus ;)

[Cybaer]

Hi,

(X)HTML- und CSS-Quelltext ist „Nerds“ vorbehalten, die anderen benutzen Editierwerkzeuge oder CMS, welche ihrerseits vernünftigen XHTML-2.0- bzw. CSS3-Code generieren.

Was ich schade fände, denn den Anspruch, mit dem HTML angetreten ist (und so über alle Maßen erfolgreich wurde!), mit einfachsten Mitteln jedermann das Publizieren zu ermöglichen, würde IMHO leiden.

Ansonsten teile suits Auffassung.

Außerdem: Klar, mit XML->CMS->XHTML geht das. Aber nach meiner Erfahrung möchten die Leute schon ein wenig mehr machen. Bzw. jedenfalls mehr, als in einem so starren System möglich ist (was aber vielleicht an unzureichenden Systemen liegen mag).

Und: Ich kann mir natürlich durchaus vorstellen, daß wir in 10 Jahren alle glücklich mit XHTML x & CSS x sein werden, und (fast) alle wirklich nur noch mit Tools arbeiten (es gibt ja auch heute noch Anwender, die z.B. LaTEX per Hand schreiben). Aber mom. erscheint mir die Qualität aktuellen Tools noch nicht so berauschend zu sein. Ob das nun an den Tools liegt, oder "nur" an deren Bedienung (was letztlich ja auch ein Problem der Tools ist), kann einem wohl egal sein. Auch da teile ich suits Einstellung ...

There are no good texts on JavaScript programming. Most of the people on the web who are producing JavaScript programs learned ist by copying really bad examples from bad books, bad websites, and bad tools.
Damit meint er sowas wie '<script>' (ohne 'type'-Attribut)? ;->

LOL :-)))

Gruß, Cybaer

[molily]

Hallo,

Bestimmt gabe es hier schon Diskussionen. Mit welchem Ergebnis?

Mit dem Ergebnis, dass du XHTML verwenden solltest, wenn du die Eigenheiten von XHTML zu deinem Vorteil nutzen kannst.

Mathias

[moor]

Hallihallo!
Ich habe in Selfhtml ein Kapitel zu den Unterschieden zwischen HTML und XHTML gefunden, aber keinen Hinweis darauf, was man jetzt besser verwenden sollte.

Nach all dem was ich jetzt hier gelesen (und großenteils nicht verstanden) habe, warte ich am besten noch ein Weilchen, bevor ich mich in diese "verrückte" Welt der Internet-"Programmierung" stürze!
Danke Euch
moor

[Cybaer]

Hi,

Nach all dem was ich jetzt hier gelesen (und großenteils nicht verstanden) habe, warte ich am besten noch ein Weilchen, bevor ich mich in diese "verrückte" Welt der Internet-"Programmierung" stürze!

Das sollte nicht abschrecken. =:-)

HTML ist wohl für dich das richtige: Man fängt hobbymässig an - und es paßt schon meistens -, und kann dann peu a peu sein Wissen erweitern, wenn man dabei bleibt ... ;-)

Wer professionell an die Sache rangehen möchte/muß, für den gelten andere Maßstäbe (theoretisch zumindest). Aber HTML ist gerade entwickelt worden für IT-Laien. "Damals" - nur "muß" eine Webseite natürlich heutzutage CSS, JS und tunlichst auch XHTML nutzen, damit man "dazugehört" zum Kreis der "Erlauchten". Das machte die Sache dann doch wieder um einiges komplexer, was aber nicht notwendig ist, um gute/wichtige Infos ins Netz zu stellen, oder einfach damit rumzuspielen ...

Gruß, Cybaer

[suit]

Das sollte nicht abschrecken. =:-)

sehe ich auch so

HTML ist wohl für dich das richtige: Man fängt hobbymässig an - und es paßt schon meistens -, und kann dann peu a peu sein Wissen erweitern, wenn man dabei bleibt ... ;-)

aus dem grund würde ich gleich xhtml empfehlen und damits nicht so streng ist einfach mal xhtml 1.0 transitional - xhtml 1.0 strict oder xhtml 1.1 ist sicher übertrieben

die dokumente liefert man dann als text/html aus und gut ist

der vorteil an dieser sache ist, dass man sich gleich einen ordentlichen programmierstil aneignet (jaja, html programmiert man nicht) - aber wenn man gleich konsequent elementnamen und attribute klein schreibt, gewöhnt man sichs gleich so an

wenn man zuerst html schreibt und mit <P><b>hallo</b> mein name ist <EM title="mein name">joschi</EM></P> validen code produziert, ist die umstellung auf xhtml später mal ein graus, da es zeitweise länger dauert, sich die konsequente kleinschreibung anzugewöhnen - da kommts dann immer wieder mal vor dass man statt onclick onClick schreibt ;)

aber ob html oder xhtml: den validator anschmeissen ist pflicht und falsch machen kann man in beiden fällen dann nichts mehr

[Gunnar Bittersmann]

@@suit:

der vorteil an dieser sache ist, dass man sich gleich einen ordentlichen programmierstil aneignet (jaja, html programmiert man nicht)

Dann sag doch gleich „Schreibstil“. ;-)

Und zu einem ordentlichen Schreibstil gehört auch die saubere Trennung von Struktur und Darstellung, also strukturelles Markup, kein physisches.

Also Strict, nicht Transitional. Auch da ist es schwer, sich einmal angewöhnte Eseleien wieder abzugewöhnen.

Live long and prosper,
Gunnar

[suit]

Dann sag doch gleich „Schreibstil“. ;-)

natürlich - aber wer lernt ordentliches html zu schreiben tut sich später auch mit css (schon fast eine programmiersprache), javascript oder php auch nicht mehr so schwer

Also Strict, nicht Transitional. Auch da ist es schwer, sich einmal angewöhnte Eseleien wieder abzugewöhnen.

da hast du auch wieder recht - wobei es bei der strict-variante hatl ein paar dinge gibt, die man als anfänger gerne mal ausprobieren möchte, weil sie in vielen codebeispielen angeführt werden target="_blank" oder iframes - soweit ich im kopf habe, arbeitet das amazon-partnernet mit iframe-werbung und diese werbeform hat man gerne mal auf einer privaten seite eingebunden

eine weitestgehend saubere trennung von (inhalt, )struktur und darstellung kann aber auch mit transitional erreicht werden - eine 100%ige trennung von struktur und erscheinungsbild ist mit html momentan sowieso nicht möglich, da gewisse teile des inhalts einfach zur darstellung beitragen - aber das ist jetzt haarspalterei ;)

[Cybaer]

Hi,

aus dem grund würde ich gleich xhtml empfehlen und damits nicht so streng ist einfach mal xhtml 1.0 transitional - xhtml 1.0 strict oder xhtml 1.1 ist sicher übertrieben

die dokumente liefert man dann als text/html aus und gut ist

Machen wir uns nichts vor: Die aaaaabsolute Mehrzahl der vorgeblichen XHTML-Coder haben einen Validator noch nie gesehen (oder nutzen ihn zumindest nicht). Zum ersten habe ich da eine ziemlich erschreckende Studie von 119 XHTML-Websites gesehen (URL kann ich noch nachschieben). Zum zweiten muß ich öfters (kommerzielle) Websites für deren Auftraggeber abnehmen/auf Qualität überprüfen. Was ich da sehe, ist regelmäßig haarsträubend und fern jeden Validators (und das sage ich als jemand, der bewußt "invalide", besser: nicht 100% W3C-standardkonform, codet!).

der vorteil an dieser sache ist, dass man sich gleich einen ordentlichen programmierstil aneignet (jaja, html programmiert man nicht) - aber wenn man gleich konsequent elementnamen und attribute klein schreibt, gewöhnt man sichs gleich so an

Das kann man auch mit HTML. Und IMHO ist es besser, man fängt sauen mit HTML an und verbessert dann allmählich (und mit stetiger Beschäftigung hoffentlich auch zwangsläufig) seinen Stil, als das man mit XHTML anfängt, auch rumsaut, und dann irgendwann "Altlasten" hat, die nicht mehr funktionieren (und sei es als Markstein der fortschreitenden Stilverbesserung ;-)).

Und wie im Parallelposting geschrieben: Ich finde weniger Norm und mehr Möglichkeiten "rumzusauen" ja philosophischerweise nicht sooo schlecht für ein Kommunikationsmedium, das derart sinnvoll und wichtig für prinzipiell alle Menschen ist - und weiter wichtiger wird.

Aber *wenn* wir den "komplexeren" Weg den Leuten zumuten wollen, dann bitte von Anfang an richtig. Also wirklich so, daß alle Browser (mindestens aber die relevanten) klipp und klar sagen: Nö, das Dokument will ich nicht, weil Fehler da und dort.

Das wär dann wenigstes fair.

Gruß, Cybaer

[at]

Hallo.

Aber *wenn* wir den "komplexeren" Weg den Leuten zumuten wollen, dann bitte von Anfang an richtig. Also wirklich so, daß alle Browser (mindestens aber die relevanten) klipp und klar sagen: Nö, das Dokument will ich nicht, weil Fehler da und dort.
Das wär dann wenigstes fair.

Nur dir gegenüber, und das muss ja nun wirklich nicht sein.
MfG, at

[moor]

Hallihallo!
Hat vielleicht einer der XHTML-Befürworter eine (eigene) XHTML-Seite, die ich unter den diversen Browsern testen könnte?
Danke!

[suit]

Hat vielleicht einer der XHTML-Befürworter eine (eigene) XHTML-Seite, die ich unter den diversen Browsern testen könnte?

xhtml 1.0 transitional als text/html
xhtml 1.0 transitional als application/xhtml+xml
getestet unter ie6 aufwärts, safari 3, opera 9 aufwärts und firefox 2 aufwärts - die zweite variante wird unter nicht xml-fähigen browsern nicht funktioniert - das als text/html gesendete xhtml dürfte in keinem browser zu einer anderen darstellung führen als exakt der selbe code mit html 4.01 transitional (lediglich im link-element fürs stylesheet sollte der schließende slash entfernt werden)

der absolute-bug um dems in dem beispiel geht ist übrigens dieser hier:
http://www.brunildo.org/test/IE_raf3.html - der div mit der id "path" sollte bei absoluter positionierung im ie6 und 7 verschwinden

[moor]

Hallo suit,
eigentlich hatte ich an eine schöne im produktiven Einsatz befindliche XHTML-Seite gedacht.
Nun zu Deinen Beispielen:
Der Quellcode des ersten Beispiels beginnt mit:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

der des 2. Beispiels mit:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"[]>
<html xmlns="http://www.w3.org/1999/xhtml">

Sie unterscheiden sich also durch:
<?xml version="1.0" encoding="iso-8859-1"?>
Was bedeutet nun dieses ?xml?
Woran ist erkenntlich, dass Auslieferung als text/html bzw. als
application/xhtml+xml?

moor

[Cybaer]

Hi,

<?xml version="1.0" encoding="iso-8859-1"?>
Was bedeutet nun dieses ?xml?

Hoffentlich verständlich ausgedrückt: XHTML ist eine spezielle Abart von XML. Und XML-Dokumente werden so ausgezeichnet. Und auch XHTML-Dokumente sind halt XML-Dokumente (aber die XML-Kennung ist bei XHTML-Dokumenten nicht notwendig und aus praktischen Gründen auch nicht sinnvoll).

Woran ist erkenntlich, dass Auslieferung als text/html bzw. als
application/xhtml+xml?

Der Server liefert in seiner Antwort einen Response-Header mit (mehr oder weniger) wichtigen Infos für den Browser. Dort wird der Typ festgelegt, wie der Browser die Daten behandeln soll.

Den Response-Header kann man z.B. mit einem HTTP-Sniffer-Tool einsehen, das es für die wichtigsten Browser als PluIn gibt.

Gruß, Cybaer

[moor]

Hallo,

<?xml version="1.0" encoding="iso-8859-1"?>
Was bedeutet nun dieses ?xml?

Hoffentlich verständlich ausgedrückt: XHTML ist eine spezielle Abart von XML. Und XML-Dokumente werden so ausgezeichnet. Und auch XHTML-Dokumente sind halt XML-Dokumente (aber die XML-Kennung ist bei XHTML-Dokumenten nicht notwendig und aus praktischen Gründen auch nicht sinnvoll).

Soweit so gut, aber warum ist dann die Zeile nicht in beiden Beispielen angegeben?

Woran ist erkenntlich, dass Auslieferung als text/html bzw. als
application/xhtml+xml?

Der Server liefert in seiner Antwort einen Response-Header mit (mehr oder weniger) wichtigen Infos für den Browser. Dort wird der Typ festgelegt, wie der Browser die Daten behandeln soll.

Ich dachte aber, ich müsste irgendwie mitteilen, wie ich meinen Code interpretiert haben möchte (text/html oder application/xhtml+xml).

Gruß
moor

[suit]

Soweit so gut, aber warum ist dann die Zeile nicht in beiden Beispielen angegeben?

diese zeile ist eine information für den xml parser damit er weiss, was er mit dem restlichen dokument anfangen soll

das attribut "version" ist zwingend und wird prinzipell auf 1.0 gesetzt, weils eigentlich keine andere xml-version gibt - nachfolgend kommt zb die zeichencodierung (diese muss nur angegeben werden, wenn sie von utf-8 abweicht)

im zweiten beispiel ist diese zeilen enthalten, weil das zweite beispiel als application/xhtml+xml ausgeliefert wird

Ich dachte aber, ich müsste irgendwie mitteilen, wie ich meinen Code interpretiert haben möchte (text/html oder application/xhtml+xml).

wird ja auch gemacht - im http-header oder in den meta-informationen (http-equiv) - im ersten fall text/html, im zweiten eben application/xhtml+xml

den unterschied bei den beiden beispielen wirst du im internet explorer sehen, der kann mit application/xhtml+xml nix anfangen und wird dir das dokument zum download anbieten

wie schon erwähnt lässt sich xhtml prolemlos als text/html ausliefern, da xml wie auch html eine sgml-teilmenge ist und von einem html-browser verstanden wird - nur umgekehrt gehts eben nicht, da html-dokumente zu "locker" für einen xml parser sind

von der seite spricht eben nichts gegen die verwendung von xhtml

[Ingo Turski]

Hi,

den unterschied bei den beiden beispielen wirst du im internet explorer sehen, der kann mit application/xhtml+xml nix anfangen und wird dir das dokument zum download anbieten

und als Alternative leider nicht "Öffnen (mit...)" sondern nur "Suchen". Diese Alternative ist aber auch sehr aufschlußreich und öffnet bei mir im Firefox die Microsoft-Infoseite:

"Windows has the following information about this MIME type. This page will help you find software needed to open your file.

MIME Type: application/xhtml xml

Description: UnKnown
Windows does not recognize this MIME type.
[...]"

Auch wenn der IE den Typ nicht kennt, warum Microsoft nicht bei: "Copyright © 2008 Microsoft Corporation."? ;-)

freundliche Grüße
Ingo

[moor]

Hallo

wird ja auch gemacht - im http-header oder in den meta-informationen (http-equiv) - im ersten fall text/html, im zweiten eben application/xhtml+xml

In beiden Beispielen habe ich weder http-header noch http-equiv gefunden.
Gruß
moor

[Harlequin]

Yerf!

In beiden Beispielen habe ich weder http-header noch http-equiv gefunden.

Die HTTP-Header stehen auch nicht *im* Quelltext. Geh mal im Firefox auf "Seiteninformationen anzeigen" und schau, was unter "Typ" steht.

Gruß,

Harlequin

[moor]

Hallo,

Die HTTP-Header stehen auch nicht *im* Quelltext. Geh mal im Firefox auf "Seiteninformationen anzeigen" und schau, was unter "Typ" steht.

Da steht es in der Tat!
Aber woher hat der Browser diese Information, wenn nicht aus dem Quelltext?
Auf dieser Selfhtml-Seite steht (im Gegensatz zu den beiden Beispielen) die Angabe
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
im Quelltext und ist auch in der Ansicht/Quelltext zu sehen.

Gruß,
moor

[Harlequin]

Yerf!

Aber woher hat der Browser diese Information, wenn nicht aus dem Quelltext?

Aus dem HTTP-Protkoll. Dabei wird nicht nur der HTML-Text übertragen, sondern davor auch noch zusätzliche Angaben, die HTTP-Header. Diese bekommt man im Browser nur über die Seiteninformationen oder spezielle PlugIns zu sehen.

Auf dieser Selfhtml-Seite steht (im Gegensatz zu den beiden Beispielen) die Angabe
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
im Quelltext und ist auch in der Ansicht/Quelltext zu sehen.

Diese Angabe ist optional und für den Fall, das keine HTTP-Header zur Verfügung stehen (z.B. wenn man die Datei direkt von der Festplatte öffnet). Sind beide Angaben vorhanden und widersprechen einander, dann "gewinnt" der HTTP-Header.

Gruß,

Harlequin

[suit]

Diese bekommt man im Browser nur über die Seiteninformationen oder spezielle PlugIns zu sehen.

Tamper Data zum beispiel

[moor]

Hi!
Seid mir nicht böse, aber ich blicke nach wie vor nicht durch!
Wie ich die HTTP-Header Info, finde habt ihr mir ja ausführlich erläutert, was nimmt aber das System defaultmäßig an, wenn keine Angaben im Quelltext vorhanden sind wie in den Beispielen
http://rebell.at/temp/absolute_bug/
und
http://schneegans.de/xp/?url=http%3A%2F%2Frebell.at%2Ftemp%2Fabsolute_bug%2F&ct=application%2Fxhtml%2Bxml

Gruß
moor

[Harlequin]

Yerf!

Wie gesagt, der HTML-Quelltext ist nicht alles, was an den Browser gesendet wird. Hier mal ein Mitschnitt aus einem Proxy (Fiddler2):

HTTP/1.0 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 16 Jul 2008 14:43:22 GMT
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Cache-Control: private
Content-Type: application/xhtml+xml; charset=iso-8859-1
Content-Length: 1030
X-Cache: MISS from proxy3.site
X-Cache-Lookup: MISS from proxy3.site:3128
Proxy-Connection: keep-alive

<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"[]>
<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <title>Title</title>
  <link rel="stylesheet" type="text/css" href="http://schneegans.de/xp/?url=http%3A%2F%2Frebell.at%2Ftemp%2Fabsolute_bug%2Fscreen.css&amp;ct=application%2Fxhtml%2Bxml" />
 </head>
 <body>
[...]

Alles bis zur ersten Leerzeile (also bis "Proxy-Connection: keep-alive") sind die HTTP-Header. Diese werden dir in der Quelltext-Ansicht des Browsers nicht mit angezeigt, da sie nicht zum HTML-Dokument, sondern zum HTTP-Request gehören. Dennoch sind sie vorhanden und liefern wichtige Informationen für den Browser, z.B. den Content-Type.

Ohne eine Angabe des Content-Type (also weder im HTTP noch als Meta) kann der Browser nur raten, was da eigentlich an Inhalt kam. Das dürften wohl zu einer Auswahl aus text/html, text/plain oder irgendetwas binäres führen.

Gruß,

Harlequin

[moor]

Hi,
Ich bin hartnäckig!

Ohne eine Angabe des Content-Type (also weder im HTTP noch als Meta) kann der Browser nur raten, was da eigentlich an Inhalt kam. Das dürften wohl zu einer Auswahl aus text/html, text/plain oder irgendetwas binäres führen.

Ich habe jetzt auf einigen homepages folgendes oder ähnliches gefunden
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
.....
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

wohlgemerkt im Quelltext der im Browser angezeigt wird.
So etwas fehlt in den Beispielen von suit.
In den beiden Beispielen von suit hat er offensichtlich gut geraten, denn er hat jeweils das Richtige gewählt.
Gruß
moor

[Harlequin]

Yerf!

Ich habe jetzt auf einigen homepages folgendes oder ähnliches gefunden
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
.....
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

wohlgemerkt im Quelltext der im Browser angezeigt wird.

*seufz*

Ja, die <meta>-Angabe steht im Quelltext. Allerdings ist diese *optional*, das Attribut "http-equiv" soll darauf hinweisen, dass sie equivalent zum entsprechenden HTTP-Header ist.

So etwas fehlt in den Beispielen von suit.

Ist auch nicht notwendig.

In den beiden Beispielen von suit hat er offensichtlich gut geraten, denn er hat jeweils das Richtige gewählt.

Nein. Ich hatte doch den Ausschnitt aus der *kompletten* Kommunikation zwischen Server und Browser gepostet (die stammt von dem XHTML-Beispiel). In diesem sieht man, das in den HTTP-Headern, die vor dem Quelltext gesendet werden die entsprechende Content-Type Angabe[1] mitgesendet wird. Somit muss der Browser nicht raten.

Gruß,

Harlequin

[1]: Content-Type: application/xhtml+xml; charset=iso-8859-1

[moor]

Hi,
ich rotiere, vorletzter Versuch:

Nein. Ich hatte doch den Ausschnitt aus der *kompletten* Kommunikation zwischen Server und Browser gepostet (die stammt von dem XHTML-Beispiel). In diesem sieht man, das in den HTTP-Headern, die vor dem Quelltext gesendet werden die entsprechende Content-Type Angabe[1] mitgesendet wird. Somit muss der Browser nicht raten.

Vielleicht verstehen wir etwas unterschiedliches unter Quelltext?
Ich habe doch im einfachsten Falle eine Datei xxx.html. In dieser Datei
(für mich: in diesem Quelltext) stehen zu Beginn z.B. die nachfolgenden Angaben. Dies sind doch die besagten HTTP-Daten?

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"[]>
<html xmlns="http://www.w3.org/1999/xhtml">

Ich habe einen Beitrag von suit nochmal gelesen und vielleicht jetzt verstanden?
Die Angabe <?xml version="1.0" encoding="iso-8859-1"?>
bewirkt die Auslieferung als application/xhtml+xml.
Vielleicht habe ich mich versteift, irgendwo im Quelltext explizit text/html bzw. application/xhtml+xml zu finden?
Gruß
moor

[Harlequin]

Yerf!

Vielleicht verstehen wir etwas unterschiedliches unter Quelltext?

Ja, das sieht so aus. (Obwohl eigentlich nicht... aber ich versuchs nochmal den Knoten zu lösen)

Ich habe doch im einfachsten Falle eine Datei xxx.html. In dieser Datei
(für mich: in diesem Quelltext) stehen zu Beginn z.B. die nachfolgenden Angaben. Dies sind doch die besagten HTTP-Daten?

Nein, das ist HTML. Wenn man diese Datei lokal von der Festplatte öffnet ist auch nie HTTP (das Übertragungsprotokoll des Webservers) im Spiel.

Sobald man aber einen Browser benutzt um diese Datei von einem Webserver zu laden kommt zusätzlich HTTP ins Spiel. Dies geschieht jedoch im Hintergrund und wird vor dem Benutzer versteckt. Trotzdem liefert der Webserver zusätzliche Angaben (die HTTP-Header eben) zum ausgeliferten HTML-File mit, die eben auch den Content-Type angeben können.

Wenn du dir mein Beispiel nochmal ansiehst, wirst du sehen, dass vor dem XHTML

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"[]>
<html xmlns="http://www.w3.org/1999/xhtml">

noch eine ganze Reihe an Zeilen mit verschiedenen Angaben erscheint. Das sind die HTTP-Header. Aber diese werden eben von einem Browser in der Quelltext-Ansicht nicht mit angezeigt.

Vielleicht habe ich mich versteift, irgendwo im Quelltext explizit text/html bzw. application/xhtml+xml zu finden?

Der Punkt ist eher, dass der Browser vom Webserver mehr als nur den HTML-Quelltext bekommt.

Die Web-Developer-Toolbar für den Firefox ist eine Möglichkeit, sich diese Header anzeigen zu lassen (dort unter Informationen -> View Response Headers)

Gruß,

Harlequin

[moor]

Hi,

Sobald man aber einen Browser benutzt um diese Datei von einem Webserver zu laden kommt zusätzlich HTTP ins Spiel. Dies geschieht jedoch im Hintergrund und wird vor dem Benutzer versteckt. Trotzdem liefert der Webserver zusätzliche Angaben (die HTTP-Header eben) zum ausgeliferten HTML-File mit, die eben auch den Content-Type angeben können.

Dass noch zusätzliche Infos geliefert werden ist mir klar.
Betrachten wir aber nur die Doctype-Angabe.
Diese kann das System doch nur aus den entsprechenden Angaben im Quelltext entnehmen bzw. "erraten". Und dies egal ob man die Datei lokal von der Festplatte öffnet oder im Browser.
Nachdem diese Angaben in den beiden Beispielen gleich sind bis auf die <?xml-Angabe müsste doch diese Angabe die Interpretation als application/xhtml+xml verursachen?
Gruß
moor

[suit]

Dass noch zusätzliche Infos geliefert werden ist mir klar.

nein, die http-header sind die primäre information

Betrachten wir aber nur die Doctype-Angabe.

das ist schon viel später ;)

Diese kann das System doch nur aus den entsprechenden Angaben im Quelltext entnehmen bzw. "erraten". Und dies egal ob man die Datei lokal von der Festplatte öffnet oder im Browser.

jein, der mime-typ unter windows wird aus aus der dateiendung und dem quelltext erraten - aber ein webserver macht das in der regel etwas gefinkelter

Nachdem diese Angaben in den beiden Beispielen gleich sind bis auf die <?xml-Angabe müsste doch diese Angabe die Interpretation als application/xhtml+xml verursachen?

die <?xml angabe ist eine steuerinformation für den xml-parser die in der tat zum quelltext gehört, diese hat aber mit dem mime-type nix zu tun

also ganz langsam von vorne:

nachdem du eine anfrage an den server geschickst hast ("ich will example.com/index.html haben") - den http-teil hierfür sparen wir uns mal, macht der server etwa folgendes:

er sieht .html ist die dateiendung und in meiner konfiguration steht, ich soll das ganze als "text/html" ausliefern (bei der endung .png wird in seiner config zb "image/png" stehen) weiters wird er irgendwo eine information zur zeichencodierung finden - da steht meinetwegen in der config "jedes dokument wo hinten .html dran steht wird als iso 8859-1 ausgeliefert"

jetzt stellt er einen http-header zusammen:

Server: Apache, Debian Etch, PHP 5.2

• eine information die einfach sagt "Hallo, das bin ich"
  Last-Modified: Tue, 10 Dec 2007 13:37:00 GMT
• eine information für den client, wann die ressource zuletzt modifziert wurde - das ist für den browser-cache wichtig, dh es kann geprüft werden ob es überhaupt lohnt, die inhalte herunterzuladen
  Content-Length: 1024
• sagt: "jetzt kommen 1024 bytes an code geliefert"
  mit diesen informationen ist es dem browser noch vollig egal, was im quelltext steht - für ihn ist es jetzt erstmal eine 1024 bytes lange textwurst die zum letzten mal im dezember 2007 verändert wurde
  Content-Type: text/html; charset=ISO 8859-1
  hier wird jetzt der mime-type und die zeichencodierung angegeben und das ruft eine routine im browser auf die ihm sagt, was er damit tun soll
  wenn da text/html steht, weiss der browser "ah, interpretiere es als html" wenn "image/png" da steht, dann wirft er seine bildanzeigeroutine an, wenn da "text/plain" steht, zeigt er 1:1 den text an usw
  200 OK
  der Statuscode - 404 File not Found oder 301 Redirect Permanent kennst du sicher auch schon - auf diesen kann der client ggf auch reagieren

und JETZT erst nachdem diese header empfangen wurden entscheidet der browser ob er überhaupt etwas herunterladen will

wenn das änderungsdatum vor dem letzten herunterladen liegt, wird ers nicht neu holen und dir zb den cache anzeigen

in unserem fall entscheidet sich der browser jetzt für "ja", schaltet seine routine für "text/html" ein und bekomt die textwurst folgendermaßen geliefert:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"[]>
<html xmlns="http://www.w3.org/1999/xhtml">

die layout engine sorgt nun dafür, dass der quelltext so dargestellt wird wie gewünscht

anstatt dem http-header
  Content-Type: text/html; charset=ISO 8859-1
könnte genausogut im gelieferten quelltext folgedes stehen:
  <meta http-equiv="Content-Type" content="text/html; charset=ISO 8859-1" />

das erfüllt den selben zweck und ist dafür da, wenn man die seiten ohne server betrachten will - sind beide vorhanden, zählt immer die angabe des servers, die im quelltext ist nutzlos - fehlen beide angaben, wird ein browser aufgrund eigener routinen selbst raten und ggf an der dateiendung entscheiden und zb bei .gif automatisch "image/gif" verwenden und sein standardverhalten "zeige den quellcode als bild an" durchziehen

bei der auslieferung als application/xhtml+xml (egal ob im http-header oder als meta-angabe - ich hoffe das ist mittlerweile klar) wird der browser ebenfalls versuch sein standardverhalten für diesen mime-type benutzen - im falle des firefox ist das "parse mich als xml-dokument", im falle des internet explorer ist es "applicaton/xhtml+xml kenne ich nicht, ich behandle es einfach als text/plain oder leite dich auf die microsoft-mime-type-liste weiter" - das selbe verhalten kannst du auch beobachten, wenn du ein pdf-dokument herunterladen willst, aber kein pdf-plugin hast -der browser wird dir das ding zum download anbieten, wenn er ein plugin hat um pdf darzustellen wird er den quelltext an das plugin weiterreichen

jetzt haben wir also application/xhtml+xml

in einem xml-dokument ist in der ersten zeile der steuerbefehl für den parser <?xml version="1.0" ?> enthalten - heisst im endeffekt nix anderes "hey parser, ich bin eine xml-datei nach version 1.0" - danach kommt der quellcode wie gehabt - der doctype (hier wird bestimmt, wie die elemente heissen müssen, wie sie verschachtelt sein dürfen

der unterschied zwischen normalem html-rendering und dem rendern durch einen xml-parser ist schlichtweg die geschwindigkeit

html beginnt sequentiell von oben nach unten - wenn der datenstrom abreisst, ist das auch nicht so schlimm und die seite wird halt "kaputt" dargestellt

ein xml parser hingegen erwartet sich einen vollständigen baum den er erstmal einliest und dann ann die html-engine weitergibt, diese kann dann mti den zuvor gesammelten informationen (zb verschachtelungstiefe, attribute usw) wesentlich schneller die seite darstellen, da sich die engine nicht selbst "durchhangeln" muss

der vorteil für (x)html-seiten ist in diesem fall zwar nicht sonderlich groß, der vorteil ist aber schlichtweg, dass die seite aufgrund ihres schemas (xhtml 1.0 transitional) von jedem xml-parser gelesen werden kann - so lassen sich als xml ausgelieferte xhtml-dokumente sehr schnell einlesen und in andere formate transformieren - aktuell sind dafür noch formate wie rss/atom nötig, in zukunft (mit xhtml 2.0) welches nur noch als echtes xml ausgeliefert werden können soll, werden viele möglichkeiten von rss/atom direkt in xhtml umsetzbar sein - bisher baut man eine html seite, eine aggregationsdokuemnt (rss), eine sitemap usw - obwohl man ansich schon ein format hat, welches maschinenlesbar wäre

aber: ums nochmal auf den punkt zu bringen - wenn man html 4.01 mit xhtml 1.0 vergleicht und als html behandelt (mime-type: text/html) ergibt sich sowohl von der darstellung, alsauch der weiterverarbeitkeit und der rendergeschwindigkeit kein unterschied - auch nicht für uralte browser - jeder browser der mit html 4.01 umgehen kann, kann auch mit xhtml 1.0 als text/html umgehen (bugs ausgenommen)

[moor]

Hi,
bevor ich das ganze versuche zu verstehen eine kurze Bemerkung zu:

nachdem du eine anfrage an den server geschickst hast ("ich will example.com/index.html haben") - den http-teil hierfür sparen wir uns mal, macht der server etwa folgendes:

er sieht .html ist die dateiendung und in meiner konfiguration steht, ich soll das ganze als "text/html" ausliefern ......

Gunnar hat um 21:16 geschrieben, dass die Interpretation der Dateiendung bei lokalen Dateien erfolgt!

Gruß
moor

[Gunnar Bittersmann]

@@moor:

Gunnar hat um 21:16 geschrieben, dass die Interpretation der Dateiendung bei lokalen Dateien erfolgt!

Hat er. Stimmt ja auch.

Und bei Ressourcen, die über HTTP kommen, anhand der HTTP-'Content-Type'-Angabe.

Dass der Server diese 'Content-Type'-Angabe auch anhand von Dateiendungen setzt*, darüber hatte ich mich gar nicht ausgelassen. Ist ja auch ’ne andere Baustelle.

Live long and prosper,
Gunnar

* frei konfigurierbar; du kannst deinem Server auch sagen: liefere alle Dateien mit der Endung '.foo' als 'text/html' aus

[Gunnar Bittersmann]

@@suit:

bei der auslieferung als application/xhtml+xml (egal ob im http-header oder als meta-angabe - ich hoffe das ist mittlerweile klar)

Dir offenbar nicht. ;-)

Bei lokalen Dateien entscheidet das Betriebssystem anhand der Dateiendung, wie die Datei verarbeitet wird. Die 'http-equiv'-Angabe ist völlig egal; aus ihr kann „nur“ noch die Zeichencodierung entnommen werden.

Hast du eine Datei mit der Endung '.html', wird sie durch den Tagsoup-Parser geschickt. Wenn dieser dann
  <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
liest, ist es zum Einschalten des XML-Parsers längst zu spät.

Live long and prosper,
Gunnar

[moor]

@@alle:
Da steh' ich nun ich armer moor (Tor) und bin so klug als wie zuvor.
Meint Ihr nicht, dass ein Nichtprofi durch Eure Beiträge überfordert ist?
Hinzu kommt, dass viele Beiträge offensichtlich nicht richtig sind, da sie umgehend von anderen richtiggestellt werden.
Wäre es vielleicht möglich, in einfachen Worten zu erläutern, warum die beiden Beispiele von suit als XHTML interpretiert werden (wohl durch die Endung) und dann einmal als text/html und einmal als application/xhtml+xml.
Es ist nicht nötig, zu erläutern welche Komponente etwas interpretiert sondern es genügt:

xxx bewirkt die Interpretation als ....
yyy bewirkt die Interpretation als ....

Danke

[Harlequin]

Yerf!

Meint Ihr nicht, dass ein Nichtprofi durch Eure Beiträge überfordert ist?

Durchaus möglich... ich bin nicht perfekt, wenns ums erklären geht. Leider weis ich im Moment auch nicht, wie ich das anders und einfacher erklären könnte.

Hinzu kommt, dass viele Beiträge offensichtlich nicht richtig sind, da sie umgehend von anderen richtiggestellt werden.

Soweit ich das gesehen hab waren sie eher in Details etwas ungenau, aber vielleicht war das ja der Fehler, zu tief in die Details einzusteigen.

Wäre es vielleicht möglich, in einfachen Worten zu erläutern, warum die beiden Beispiele von suit als XHTML interpretiert werden (wohl durch die Endung) und dann einmal als text/html und einmal als application/xhtml+xml.

Ich probiers nochmal auf die Art:

Es ist nicht nötig, zu erläutern welche Komponente etwas interpretiert sondern es genügt:

xxx bewirkt die Interpretation als ....

Content-Type: application/xhtml+xml; charset=iso-8859-1

bewirkt die Interpretation als XHTML.

yyy bewirkt die Interpretation als ....

Content-Type: text/html; charset=ISO-8859-1

bewirkt die Interpretation als HTML.

Falls du diese Zeilen jetzt in den Beispielen von suit suchst: diese werden *nicht* in der Quelltextansicht angezeigt, sondern nur mittels eines Tools, das die HTTP-(Response)-Header anzeigt.

Gruß,

Harlequin

[moor]

Hallo,

xxx bewirkt die Interpretation als ....

Content-Type: application/xhtml+xml; charset=iso-8859-1

bewirkt die Interpretation als XHTML.

yyy bewirkt die Interpretation als ....

Content-Type: text/html; charset=ISO-8859-1

bewirkt die Interpretation als HTML.

Falls du diese Zeilen jetzt in den Beispielen von suit suchst: diese werden *nicht* in der Quelltextansicht angezeigt, sondern nur mittels eines Tools, das die HTTP-(Response)-Header anzeigt.

Was ich eigentlich immer wissen wollte, wo wird es angegeben?
Also doch offensichtlich in der Source(Datei), wobei diese Zeile nicht angezeigt wird.
Gruß
moor

[Harlequin]

Yerf!

Was ich eigentlich immer wissen wollte, wo wird es angegeben?
Also doch offensichtlich in der Source(Datei), wobei diese Zeile nicht angezeigt wird.

Wo es er Author angibt? In der Konfiguration des Webservers, denn dieser ist dafür verantwortlich, die HTTP-Header zu generieren. Meistens ist dies eine Zuordnung augrund der Dateiendung. (Er könnte auch den Dateiinhalt analysieren aber für die meisten Fälle wäre das zu aufwändig.)

Bei serverseitigen Skripten (z.B. PHP) kann dies aber auch über das Skript selbst gesteuert werden (in PHP per header() ).

Gruß,

Harlequin

[moor]

Hallihallo,

Meistens ist dies eine Zuordnung augrund der Dateiendung.

Oh! Anhand der Endung soll das System erkennen ob
text/html oder application/xhtml+xml?

[Harlequin]

Yerf!

Oh! Anhand der Endung soll das System erkennen ob
text/html oder application/xhtml+xml?

Das System ist dabei aber der Webserver und nicht der Client (Browser). Der Browser richtet sich nach dem vom Webserver angegebenen Content-Type, egal wie dieser zustande kam.

Außerdem gibt es zumindest beim Apache vielfältige Möglichkeiten das anders zu regeln und händisch in den Prozess einzugreifen. Z.B. kann man den Typ überschreiben oder aus dem Inhalt ermitteln lassen. Die Zuordnung über die Dateiendung ist nur eine einfache Grundkonfiguration, die allerdings für die meisten Zwecke auch ausreicht.

Serverseitige Skripte können ja Problemlos selbst die HTTP-Header erzeugen und damit unabhängig von der Webserverkonfiguration den Content-Type vorgeben (das Skript weis wohl selber auch am besten, was für Daten es ausgibt).

Gruß,

Harlequin

[moor]

Hallihallo!
Leider nach wie vor unbefriedigend.
Du kommst wieder vom Hundertsten ins Tausendste.
Wie ich geschrieben habe, interessiert mich nicht, wer was wann wo macht, daher schreibe ich stellvertretend "System".
Mich interessierte, woher das "System" die Information hat zu entscheiden, wie er eine Datei zu interpretieren hat (z.B. an den Beispielen von suit), wenn nicht aus deren Endung und Beschreibungen innerhalb des Dateiinhalts - egal, ob diese Information nun in der Ansicht des Quelltextes sichtbar sind oder nicht.
Da wir aber offensichtlich nicht weiterkommen und der thread bald die Grenzen von Selfhtml sprengt, gebe ich auf.
Dank an alle
moor

[Harlequin]

Yerf!

Wie ich geschrieben habe, interessiert mich nicht, wer was wann wo macht, daher schreibe ich stellvertretend "System".

Das Problem ist nur, dass man es ohne diese Unterscheidung nicht erklären kann. Außer du gibst dich mit der Umschreibung "Voodoo" zufrieden...

Gruß,

Harlequin

[Vinzenz Mai]

Hallo

Mich interessierte, woher das "System" die Information hat zu entscheiden, wie er eine Datei zu interpretieren hat (z.B. an den Beispielen von suit), wenn nicht aus deren Endung

a) doch aus der Endung
b) weil jemand anderes es dem System für genau diese Datei vorgibt.

Da wir aber offensichtlich nicht weiterkommen

Es ist leider schwierig nachzuvollziehen, wo Du hängengeblieben bist - und was Du wirklich wissen willst.

und der thread bald die Grenzen von Selfhtml sprengt,

Naja, bis zum Rekordthread fehlen noch über 400 Beiträge.

gebe ich auf.

Schade.

Freundliche Grüße

Vinzenz

[Joklet]

Hallo,
habe den thread etwas verfolgt. Habe als Internet-Greenhorn nicht viel verstanden, als Mathematiker allerdings seine Fragestellung und ich habe
n i c h t    verstanden diese ausschweifenden Ausführungen zu dem was der Server macht, was die Komponente xyz macht etc.
Es muss doch möglich sein, in einer Datei xyz.xhtml die Informationen weiterzugeben, dass diese Datei als text/html bzw. als das andere G'schmarri (wie man in Bayern sagt) application/xhtml+xml interpretiert wird.
Diese Datei lädt der "Entwickler" auf den Server1 oder 2 oder 3 und es sollte, wenn es nicht Exotenserver sind, beim Aufruf von Browser1, 2 oder 3 (wenn es nicht Exoten sind wie der IE) dies Datei als text/html bzw. application/xhtml+xml interpretiert wird.
Also erklärt ihm doch einfach, was in der Datei stehen muss und nicht, was im Source-code sichtbar ist und was nicht.
Freundliche Grüße
Joklet

[Harlequin]

Yerf!

Es muss doch möglich sein, in einer Datei xyz.xhtml die Informationen weiterzugeben, dass diese Datei als text/html bzw. als das andere G'schmarri (wie man in Bayern sagt) application/xhtml+xml interpretiert wird.

Nein, da der Browser diese Information braucht, bevor er anfängt die Datei einzulesen. Anonsten müsste der Browser die datei 2 mal lesen, einmal zum analysieren und ein 2. mal zum interpretieren (XML-Parser haben eine eigene Vorgehensweise, die sich von reinem Text-Lesen unterscheidet)

Also erklärt ihm doch einfach, was in der Datei stehen muss und nicht, was im Source-code sichtbar ist und was nicht.

Der Entwickler legt dies über die Serverkonfiguration und nicht über den Dateiinhalt fest. (Noch einfacher und klarer kann man es glaub ich nicht ausdrücken)

Gruß,

Harlequin

[Ingo Turski]

Hi,

Also erklärt ihm doch einfach, was in der Datei stehen muss und nicht, was im Source-code sichtbar ist und was nicht.

Der Entwickler legt dies über die Serverkonfiguration und nicht über den Dateiinhalt fest. (Noch einfacher und klarer kann man es glaub ich nicht ausdrücken)

ich versuch's dennoch mal anhand eines ähnlichen Beispiels, nämlich HTML-E-Mails. Auch diese bestehen aus (mindestens) zwei Teilen:

1. Den Mail-Headern. Hierin steht bei als HTML anzuzeigenden Mails auch die Information hierüber, z.B.:
  Content-Type: text/html; charset=utf-8
Das ist genauso wie bei Webservern. Gute Mailprogramme bieten - genauso wie gute bzw. erweiterte Browser - die Möglichkeit, diese Header anzuzeigen.

2. Durch doppelten Zeilenumbruch getrennten Mail-Body.
Das ist das, was das empfangende Mailprogramm anzeigt und analog bei Browsern auch das, was diese normalerweise nur anzeigen.

Fehlt in der E-Mail diese Header-Angabe, dass es sich um text/html handelt, dann wird das Mailprogramm den HTML-Code auch nicht umsetzen, sondern nur den Quellcode als Text anzeigen.

Wie kommen diese Header nun zustande?
Sie werden nicht einfach in den Inhalt einer Mail bzw. analog einer HTML-Seite geschrieben, sondern vor dem Inhalt eingefügt. Im Falle einer Mail, die z.B. mit Thunderbird geschrieben wird, eben von diesem Programm (sofern der Benutzer ein Häkchen in den Konteneinstellungen bei "Nachrichten im HTML-Format verfassen" gesetzt hat) oder wenn die Mail z.B. von einem PHP-Programm verschickt wird, über einen Zusatzparameter für "additional headers" im mail()-Aufruf.
Nehmen wir nun einen Webserver. Hier gibt es anstatt Häkchen für das Senden des Content-Types Konfigurationsdateien. Über diese kann man den Server so einstellen, dass er _vor_ der Auslieferung von Dateien, deren Namen mit ".html" enden, die Zeichenfolge
  Content-Type: text/html
übermittelt. Vorher oder nachher wird er noch weitere Header-Informationen senden, dann einen doppelten Zeilenumbruch als Kennzeichnung des Endes der Headerzeilen und _dann_ erst die Daten der *.html-Datei.
Es ist also nichts _in_ der HTML-Datei, was den Server zum Senden des Content-Type veranlasst, sondern schlicht die Namensendung der Datei.

Hat man nun eine *.html-Datei lokal auf seinem Windows-Rechner und doppelklickt sie im Datei-Explorer, passiert im Prinzip das gleiche. Windows ist so vorkonfiguriert, dass es *.html-Dateien als Typ HTML erkennt und den hiermit verknüpften Standardbrowser aufruft. Der Browser kann die Datei dann ebenfalls anhand der Namenserweiterung als HTML einstufen oder auch den Inhalt analysieren.

freundliche Grüße
Ingo

[Joklet]

Na,ja!

Der Entwickler legt dies über die Serverkonfiguration und nicht über den Dateiinhalt fest. (Noch einfacher und klarer kann man es glaub ich nicht ausdrücken)

... falscher wohl auch nicht!

Kleine Anwender, zu denen ich moor aber auch mich zähle, die irgendwo einen Hoster gefunden haben, haben doch wohl keinen Einfluss auf die Server-Konfiguration.
Wenn ich von mir ausgehe, so steht am Anfang meiner Datei
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
.....
was auch nach dem Umzug zu einem anderen Provider (und damit Server) funktionierte.
Und gerade habe ich eine zufällige Seite mit XHTML-Angaben aus dem Web geholt und auf 'meinen' Server geladen. Diese funktioniert ebenfalls ohne dass ich meinen Provider bitten musste, etwas zu verändern.
(Natürlich habe ich die "geliehene" Seite sofort wieder gelöscht).
Schönen Tag noch (ohne Doping bei der Tour de France)

[Ingo Turski]

Hi,

Kleine Anwender, zu denen ich moor aber auch mich zähle, die irgendwo einen Hoster gefunden haben, haben doch wohl keinen Einfluss auf die Server-Konfiguration.

das stimmt zumindest - diese müssen ihre Dateien so benennen (z.B. als *.html), damit über die jeweilige Serverkonfiguration der richtige bzw. zumindest nicht ein falscher Content-Type gesendet wird.

freundliche Grüße
Ingo

[Gunnar Bittersmann]

@@Ingo Turski:

Kleine Anwender, zu denen ich moor aber auch mich zähle, die irgendwo einen Hoster gefunden haben, haben doch wohl keinen Einfluss auf die Server-Konfiguration.

Mit .htaccess oft doch in ausreichendem Maße ...

das stimmt zumindest - diese müssen ihre Dateien so benennen (z.B. als *.html), damit über die jeweilige Serverkonfiguration der richtige bzw. zumindest nicht ein falscher Content-Type gesendet wird.

... die Zuordnung Dateiendung – Content-Type sollte mit .htaccess gehen.

Live long and prosper,
Gunnar

[Ingo Turski]

Hi,

... die Zuordnung Dateiendung – Content-Type sollte mit .htaccess gehen.

sollte _auch_ - sofern das der Provider von Billig-Space überhaupt zulässt.

freundliche Grüße
Ingo

[Gunnar Bittersmann]

@@Ingo Turski:

... die Zuordnung Dateiendung – Content-Type sollte mit .htaccess gehen.
sollte _auch_ - sofern das der Provider von Billig-Space überhaupt zulässt.

Darauf spielt ich mit dem Wörtchen „oft“ an.

Live long and prosper,
Gunnar

[Harlequin]

Yerf!

Der Entwickler legt dies über die Serverkonfiguration und nicht über den Dateiinhalt fest. (Noch einfacher und klarer kann man es glaub ich nicht ausdrücken)
... falscher wohl auch nicht!

Ich wurde mehrfach dazu aufgefordert nicht in einzelne Einheiten zu zerlegen... also wohl auch nicht in Entwickler und Serveradmin, oder?

Kleine Anwender, zu denen ich moor aber auch mich zähle, die irgendwo einen Hoster gefunden haben, haben doch wohl keinen Einfluss auf die Server-Konfiguration.

Nein. Die bekommen vom Serveradmin einfach eine entsprechende Konfiguration vorgesetzt.

Wenn ich von mir ausgehe, so steht am Anfang meiner Datei
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
.....
was auch nach dem Umzug zu einem anderen Provider (und damit Server) funktionierte.

Dann hast du vermutlich die "richtige" Dateiendung verwendet. Die übliche Konfiguration der Webserver wählt den Content-Type nämlich abhängig von der Dateiendung.

Und gerade habe ich eine zufällige Seite mit XHTML-Angaben aus dem Web geholt und auf 'meinen' Server geladen. Diese funktioniert ebenfalls ohne dass ich meinen Provider bitten musste, etwas zu verändern.

Wurde sie als text/html oder als application/xhtml+xml ausgeliefert (sprich: kann der IE sie darstellen oder will er sie downloaden)? Und macht es einen Unterschied, ob du sie .html oder .xhtml nennst?

Ich würde drauf tippen, dass sie immer als text/html ausgeliefert wird (sprich: auch der IE stellt sie dar) und du ohne Eingriff in die Serverkonfiguration keine Chance hast das zu ändern.  (zumindest würde ich von 0-8/15 Hostern eine solche Konfiguration erwarten, aber das ist kein Gesetz)

Gruß,

Harlequin

[Joklet]

Nein. Die bekommen vom Serveradmin einfach eine entsprechende Konfiguration vorgesetzt.

... und können damit nach Deinen Ausführungen möglicherweise keine XHTML-Seiten erstellen.

Dann hast du vermutlich die "richtige" Dateiendung verwendet. Die übliche Konfiguration der Webserver wählt den Content-Type nämlich abhängig von der Dateiendung.

Dass die Dateiendung mit entscheidend ist hat doch schon moor geschrieben in seiner Vermutung:
"wenn nicht aus deren Endung und Beschreibungen innerhalb des Dateiinhalts - egal, ob diese Information nun in der Ansicht des Quelltextes sichtbar sind oder nicht"»»

Wurde sie als text/html oder als application/xhtml+xml ausgeliefert (sprich: kann der IE sie darstellen oder will er sie downloaden)?

Habe keinen IE.
Aber unter den Seiteninformationen kam application/xhtml+xml

Grüße
Joklet

[suit]

... und können damit nach Deinen Ausführungen möglicherweise keine XHTML-Seiten erstellen.

wieso, die http-requests und response-header lassen sich problemlos mit jeder dahergelaufenen scriptsprache auslesen - php zb

  
header("content-type: application/xhtml+xml; charset=uft-8");  

sorgt dafür, dass der server unabhängig seiner konfiguration das aktuelle dokument (sofern noch kein output gesendet wurde) als application/xhtml+xml ausliefert

oder ist das schon wieder zu viel detail?

Dass die Dateiendung mit entscheidend ist hat doch schon moor geschrieben in seiner Vermutung:
"wenn nicht aus deren Endung und Beschreibungen innerhalb des Dateiinhalts - egal, ob diese Information nun in der Ansicht des Quelltextes sichtbar sind oder nicht"»»

der webserver apache geht per default NUR nach dateiendung, den inhalt des auszuliefernden dokuments analysieren zu lassen ist aber auch eine möglichkeit

prinzipiell ist es aber egal ob ein dokument .html, .pdf, .josefundmaria oder .xhtml heisst - ich kann als serveradmin reinschreiben was ich will - wenn ich .png als text/html ausliefern lassen will und .pdf als image/gif, und .html-dateien als application/pdf bleibt mir das überlassen - es dateiendungen haben im http-kontext keine bedeutung - es müsste eigentlich überhaupt keine endungen geben, nur dateiendungen erlauben es eben, den mime-type extrem schnell zu bestimmen

bei containerformaten wie zb .avi ist das ein grosses problem, da die codec-informationen im file hinterlegt und der mime-type video/x-msvideo zur eigentlichen interpretation nur indirekt von nutzen ist, er hilft nur dabei die geeignete software zum darstellen auszuwählen

Aber unter den Seiteninformationen kam application/xhtml+xml

ja, darum wird der ie6 auch ein download-promt liefern (meiner tut das jedenfalls)

[at]

Hallo.

der webserver apache geht per default NUR nach dateiendung, den inhalt des auszuliefernden dokuments analysieren zu lassen ist aber auch eine möglichkeit

Nur um ein erneutes Missverständnis zu vermeiden: Die Analyse erfolgt nicht im Browser, sondern durch den Webserver vor dem Versenden der Ressource.
MfG, at

[Harlequin]

Yerf!

Nein. Die bekommen vom Serveradmin einfach eine entsprechende Konfiguration vorgesetzt.
... und können damit nach Deinen Ausführungen möglicherweise keine XHTML-Seiten erstellen.

Das ist durchaus möglich (wenn man den von suit angesprochenen Ansatz mal weglässt)

In den Konfigurationen der Webserver hat man schon die seltsamsten Sachen entdeckt (bekommt man so mit, wenn man hier n bischen mitliest)

Aber unter den Seiteninformationen kam application/xhtml+xml

Dann ist bei dir der Webserver entsprechend für XHTML konfiguriert.

Gruß,

Harlequin

[Joklet]

Hi,
ich wiederhole eine Aussage von moor in meinen Worten (er möge mich, falls er noch mitliest, korrigieren):
Das System (wieder stellvertretend für alle beteiligten Komponenten) entscheidet
(anhand der Dateiendung   u n d   anhand von Angaben in der Datei)
wie das Dokument zu behandeln ist.
Bei fehlenden/unvollständigen Angaben werden Defaultwerte angenommen.
Diesen Aussagen wurde wiederholt wiedersprochen.
Die Negation bedeutet aber:
Das System entscheidet   n i c h t
(anhand der Dateiendung   u n d   anhand von Angaben in der Datei)
wie das Dokument zu behandeln ist.
==>
Das System entscheidet nicht anhand der Dateiendung   o d e r   nicht anhand von Angaben in der Datei) wie das Dokument zu behandeln ist.

Dass die Endung berücksichtigt wird, wurde an mehreren Stellen von Euch geschrieben, d.h. also erfolgt keine Entscheidung anhand des Dateiinhalts.

Es wird also die Datei

Test.xhtml:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<head></head><body></body>

trotz anderslautender DOCTYPE-Angabe als application/xhtml+xml interpretiert. Oder vielleicht doch nur als text/html  oder als ?
Grüße
Joklet

[Harlequin]

Yerf!

Es wird also die Datei

Test.xhtml:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<head></head><body></body>

trotz anderslautender DOCTYPE-Angabe als application/xhtml+xml interpretiert.

Ja. Der Browser sollte auch eine entsprechende Fehlermeldung bringen, dass dies kein wohlgeformtes XML ist.

(Die Konfiguration deines Webservers aus dem vorherigen Posting als gegeben angesehen. Diese kann man nicht unbedingt verallgemeinern[1])

Gruß,

Harlequin

[1] sorry, dass ich hier immernoch auf "Details" rumreite, aber ich versuch einfach Verwirrungen zu vermeiden, wenn man mal auf einen Hoster trifft, der das im Webserver anders einstellt. Dann sollte man eben schon wissen, woran das liegt.

[Ingo Turski]

Hi,

Es wird also die Datei

Test.xhtml:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<head></head><body></body>

trotz anderslautender DOCTYPE-Angabe als application/xhtml+xml interpretiert.

ja - sofern der Webserver diesen ContentType sendet.

Und wenn kein Webserver und somit kein ContentType im Spiel ist, entscheidet der jeweilige Browser darüber - bei (meinem) Windows ebenfalls anhand der Dateiendung: der IE bietet wie üblich den Download an und Firefox verarbeitet die Datei streng als application/xhtml+xml und streikt gnadenlos beim ersten XML-Verarbeitungsfehler.

freundliche Grüße
Ingo

[Struppi]

Also erklärt ihm doch einfach, was in der Datei stehen muss und nicht, was im Source-code sichtbar ist und was nicht.

Das habe ich versucht zu erklären, dass das nicht so einfach geht, da hier mehrere Komponenten eine Role spielen. Es reicht eben nicht aus zu sagen was im Source stehen muss, es muss darüber hinaus der Server entsprechend konfiguriert werden und u.U. der IE berücksichtigt werden. Letztlich stellt sich die Frage was für ein XHTML er gerne hätte.

Struppi.

[Struppi]

Meistens ist dies eine Zuordnung augrund der Dateiendung.

Oh! Anhand der Endung soll das System erkennen ob
text/html oder application/xhtml+xml?

Der Server, nicht das System. Es scheint du verkennst die Situation und verstehst nicht was sich beim anfordern einer Datei über HTTP passiert. Das hat nichts mit dem öffnen ein er Datei auf deinem Rechner zu tun.

Wenn wir mal den ganzen Netzwerkspezifischen Krempel weglassen:

[CLIENT] (Browser)
url: example.org

Browser bastelt daraus einen Request, genaueres hier

[SERVER] Der Server nimmt den Request entgegen und erkennt welche Resource angefordert wird.

Nun gibt es viele Möglichkeiten wie dieser konfiguriert ist. Der Apache Server kann z.b. mittels mod_rewrite die URL komplett umbauen, sodass etwas völlig anderes angefordert, als im Browser steht.

Möchte der Request eine Datei, dann gibt es eine Tabelle wo den Dateiendungen ein MIME Type zugeordnet ist.

Daraus und aus den anderen Informationen, die der Browser schickt, baut der Server ein Response Header zusammen. Diesen Header bekommst du normalerweise nie zu sehen. Aber der Browser. Der Header wird in der antwort an den Browser einfach mit zwei Leerzeilen bzw. Newline Zeichen vom Rest getrennt.

Und das was im Header steht, sollte für den Browser ausschlaggebend für die Art der Darstellung sein. Leider sieht es der IE nicht so eng und bevorzugt hin und wieder die Einstellungen in deinem System.

Um sauber zu arbeiten musst du den Server so konfigurieren, wie du es möchtest. D.h. wenn du XHTML ausliefern willst, muss der Server den richtigen header liefern und _zusätzlich_ müssen deine Dateien gültiges XHTML sein. Und da fangen bei XHTML die Probleme mit dem IE an.

Soweit ich das verstehe (ich bevorzuge nach wie vor HTML) muss ein gültiges XHTML Dokument ein <?xml .... > am Anfang im Quelltext haben und  ein application/xhtml+xml im Header senden (auch hier wikipedia).

Doch so eine HTTP Anfrage bietet dir der IE 6 zum Download an, anstatt sie anzuzeigen. Deshalb musst du auf Tricks zurückgreifen (den Server so konfigurieren, dass er an manche Browser ungültiges XHTML sendet) oder auf sauberes XHTML verzichten.

Alles in allem ein nicht einfaches Thema und nicht einfach zu verstehen. Du solltest aber erst einmal versuchen die Grundlagen von HTTP zu verstehen und vielleicht mal ein bisschen mit einem Server rumspielen und mit Hilfe von Firefox Plugins die Header analysieren. Dann dürfte dir das Verständnis dieser ganzen Dinge einfacher fallen.

So! Ich hoffe ich habe nicht zuviel Unsinn geschrieben, da ich noch nach wie vor HTML bevorzuge und mich nicht mit diesen ganzen Feinheiten beschäftigen will.

Struppi.

[Ingo Turski]

Hi,

[CLIENT] (Browser)
url: example.org

Browser bastelt daraus einen Request, genaueres hier

oder ungenaueres, aber auf sehr niedrigem Niveau verständlich, bei der Maus. ;-)

wenn du XHTML ausliefern willst, muss der Server den richtigen header liefern und _zusätzlich_ müssen deine Dateien gültiges XHTML sein. Und da fangen bei XHTML die Probleme mit dem IE an.

Soweit ich das verstehe (ich bevorzuge nach wie vor HTML) muss ein gültiges XHTML Dokument ein <?xml .... > am Anfang im Quelltext haben und  ein application/xhtml+xml im Header senden (auch hier wikipedia).

Doch so eine HTTP Anfrage bietet dir der IE 6 zum Download an, anstatt sie anzuzeigen. Deshalb musst du auf Tricks zurückgreifen (den Server so konfigurieren, dass er an manche Browser ungültiges XHTML sendet) oder auf sauberes XHTML verzichten.

Du verquickst hier Dinge, die nichts miteinander zu tun haben.

1. XHTML 1.0 muss nicht als application/xhtml+xml ausgeliefert werden und auch keine xml-Deklaration haben, um vom Browser korrekt verarbeitet werden zu können.

2. Der IE stört sich nicht an der xml-Deklaration, sondern kennt lediglich application/xhtml+xml nicht.
Während der IE das als application/xhtml+xml ausgelieferte Dokument http://de.selfhtml.org/html/xhtml/anzeige/beispiel.xhtml zum Download anbietet, stellt er das gleiche, nur als application/xml ausgelieferte Dokument http://de.selfhtml.org/html/xhtml/anzeige/beispiel.xml korrekt als XML dar.

3. Der Server muss kein "unsauberes" XHTML an IEs senden, sondern ihnen XHTML nur als text/html ausliefern. Und dem IE7 darf er ja auch die xml-Deklaration vorsetzen, ohne ihn in den quirks ode zu schicken.

freundliche Grüße
Ingo

[Kai345]

[latex]Mae  govannen![/latex]

Vielleicht verstehen wir etwas unterschiedliches unter Quelltext?
Ich habe doch im einfachsten Falle eine Datei xxx.html. In dieser Datei
(für mich: in diesem Quelltext) stehen zu Beginn z.B. die nachfolgenden Angaben. Dies sind doch die besagten HTTP-Daten?

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

Neiiin, das kommt *nach* dem HTTP-Teil.

Sieh es als Telefongespräch:

(stark simplifiziert und nicht 100% übertragbar:)
Der HTTP-Teil entspricht abheben, wählen, klingeln lassen etc., genau bis der Andere abhebt.
Alles ab <!DOCTYPE ... ist dann das, was *du* mit dem Anderen redest.

Cü,

Kai

[Gunnar Bittersmann]

@@suit:

Soweit so gut, aber warum ist dann die Zeile nicht in beiden Beispielen angegeben?
diese zeile ist eine information für den xml parser damit er weiss, was er mit dem restlichen dokument anfangen soll

Das würde eine Frage beantworten, warum die XML-Deklaration da wäre; nicht aber die Frage, warum sie nicht da ist.

Die XML-Deklaration ist nicht notwendig bei XML-Version 1.0 und UTF-8- bzw. UTF-16-codierten Dokumenten (oder wenn die Zeichencodierung auf anderem Wege – da isser wieder, der HTTP-Header – mitgeteilt wird).

Die XML-Deklaration ist störend für IE 6 – sie schaltet den in den Quirks-Modus – und wird deshalb weggelassen.

das attribut "version" ist zwingend und wird prinzipell auf 1.0 gesetzt, weils eigentlich keine andere xml-version gibt

Ähm, wie bitte?! [XML11]

nachfolgend kommt zb die zeichencodierung (diese muss nur angegeben werden, wenn sie von utf-8 abweicht)

Auch das stimmt nicht ganz; s.o.

wird ja auch gemacht - im http-header oder in den meta-informationen (http-equiv) - im ersten fall text/html, im zweiten eben application/xhtml+xml

AFAIK wäre bei 'application/xhtml+xml' eine evtl. im Dokument vorhandene 'http-equiv'-Meta-Angabe sinnlos – sie wird gar nicht beachtet. [TUTORIAL-CHAR-ENC]

wie schon erwähnt lässt sich xhtml prolemlos als text/html ausliefern, da xml wie auch html eine sgml-teilmenge ist und von einem html-browser verstanden wird

Das ist kein Argument; XML und HTML sind disjunkte Teilmengen von SGML.

Anhang C [XHTML10] ist ein Argument.

Live long and prosper,
Gunnar

[moor]

@all:
Ich glaube, ich geb auf.
Was soll ich denn nun noch glauben bei all den widersprüchlichen Aussagen?
Wird nun die Angabe des Dokumententyps HTML, XHTML im Dokument angegeben oder nicht?
Falls nicht, wird dieser "erraten"?
Gruß
moor

[Gunnar Bittersmann]

@@moor:

Wird nun die Angabe des Dokumententyps HTML, XHTML im Dokument angegeben oder nicht?

Ja, im Dokument wird der Dokumententyp angegeben – in der DOCTYPE-Angabe <!DOCTYPE html ...>.

Aber selbst wenn das Dokument in XHTML geschrieben ist, heißt das nicht, dass es auch als XHTML verarbeitet wird. Und eine eventuelle vorhandene XML-Deklaration <?xml version="1.0" ...?> hat darauf überhaupt keinen Einfluss.

Ob ein XHTML-Dokument als XHTML verarbeitet wird, bestimmt die 'Content-Type'-Angabe im mitgesandten HTTP-Header. Ist diese 'text/html', so wird ein XHTML-Dokument wie ein HTML-Dokument durch den Tag-Soup-Parser gejagt (und sollte deshalb nach Anhang C kompatibel sein). Ist diese 'application/xhtml+xml', wird das Dokument als XHTML verarbeitet (z.B. in der DOCTYPE-Angabe definierte Entities aufgelöst [1, 2]).

Fehlt die 'Content-Type'-Angabe im HTTP-Header, wird ein Client das Dokument wohl als 'text/plain' verarbeiten, also den Quelltext darstellen.

Anders bei lokalen Dateien, da sagt das Betriebssystem, wie die Dokumente verarbeitet werden: Dokumente mit der Endung '.html' bspw. als HTML, solche mit der Endung '.xhtml' als XHTML. Dann erhält der Parser die Information über die Zeichencodierung bei Verarbeitung als HTML aus der 'http-equiv'-Angabe bzw. bei Verarbeitung als XHTML aus der XML-Deklaration – sofern vorhanden.

Live long and prosper,
Gunnar

[moor]

Hi Gunnar,

Ob ein XHTML-Dokument als XHTML verarbeitet wird, bestimmt die 'Content-Type'-Angabe im mitgesandten HTTP-Header.

Worum es mir die ganze Zeit geht: Woher kommt die HTTP-Header-Information? Wer erzeugt den Header?
Wenn ich eine Datei im Browser eröffne, die keine Angaben darüber enthält, ob html, xhtml, o.a. so kann doch kein System der Welt sagen, dies wird als XHTML
interpretiert, und einen entsprechenden Header senden, es sei denn die Syntax würde analysiert.
Gruß
moor

[suit]

Wenn ich eine Datei im Browser eröffne, die keine Angaben darüber enthält, ob html, xhtml, o.a. so kann doch kein System der Welt sagen, dies wird als XHTML

richtig, kein system der welt kann das sagen - aber auch auf dem server läuft ein betriebssystem - apache zb

der geht prinzipiell davon aus, wenn du eine datei index.html nennst, soll er sie als text/html ausliefern (wenn nicht anders angegeben) wenn du eine html datei meinbild.gif nennst, wird der server das ding aufgrund seiner einstellung vermutlich als image/gif verschicken weil ihn der inhalt einfach nicht interessiert

genauso wie unter windows - wenn du eine exe-datei in .html umbenennst ist der quelltext noch lange kein html, windows wird aber aufgrund der einstellung zum öffnen von html-datein einfach mal sagen "hey firefox/internet explorer, mach mal das file auf"

[suit]

richtig, kein system der welt kann das sagen - aber auch auf dem server läuft ein betriebssystem - apache zb

soll heisten "debian zb, mit apache als webserver" :D

[moor]

der geht prinzipiell davon aus, wenn du eine datei index.html nennst, soll er sie als text/html ausliefern ...

Gerade habe ich eine HTML-Datei index.html umbenannt in index.xxx und dann in den Browser geschoben und dieser hat sie korrekt als html-Datei dargestellt.

[suit]

Gerade habe ich eine HTML-Datei index.html umbenannt in index.xxx und dann in den Browser geschoben und dieser hat sie korrekt als html-Datei dargestellt.

es ist faszinierend, was die fehlerkorrektur und die vorhersage von browsern alles leisten kann

ja weil das sein standardverhalten ist - benenne eine .jpg-datei in .html um und schieb sie in den browser, der browser wird auch versuchen das html zu parsen

benenne eine html datei in .png um, der browser wird versuchen die grafik darzustellen

aber es geht hier nicht um undefiniertes verhalten sondern um definiertes ;)

[suit]

Ähm, wie bitte?! [XML11]

selfhtml sagt: 'Es gibt zwar bereits eine Version 1.1, doch die gegenwärtigen XML-Parser unterstützen normalerweise nur die Version 1.0. Da das Konzept von XML syntaktisch weitgehend ausgereift ist, ist auch nicht mit einer Versionenflut zu rechnen. Benutzen Sie also außer in begründeten Ausnahmefällen die Angabe version="1.0"'

[Cyx23]

Hallo,

Die XML-Deklaration [...] IE 6 – sie schaltet den in den Quirks-Modus [..

Was abhängig von der Vorgehensweise auch erwünscht ist, weswegen die XML-Deklaration
nicht pauschal, sondern je nach Einzelfall weggelassen wird (oder gerade nicht).

Grüsse aus Düsseldorf

Cyx23

[suit]

eigentlich hatte ich an eine schöne im produktiven Einsatz befindliche XHTML-Seite gedacht.

du wirst bei einer sauber erstellen und validen seite keinen unterschied zwischen xhtml 1.0 und html 4.01 als text/html sehen können - die seiten werden von einem html-browser exakt gleich gerendert

spotan fällt mir nix ein - ich kenne nur ein paar schlechte xml/xsl-seiten - wie zb diese hier http://www.wow-europe.com/de/index.xml - das xml-file ist zwar wohlgeformt, das transformationsergebnis durch das xsl-file ist aber weder html noch xhtml - also ein furchtbar schlechtes beispiel

[moor]

Hallo,
es wird ja immer schwieriger für mich. Was ist

gerendert

?

spotan fällt mir nix ein - ich kenne nur ein paar schlechte xml/xsl-seiten - wie zb diese hier http://www.wow-europe.com/de/index.xml - das xml-file ist zwar wohlgeformt, das transformationsergebnis durch das xsl-file ist aber weder html noch xhtml - also ein furchtbar schlechtes beispiel

Was haben diese files mit XHTML zu tun?
Ich dachte eigentlich nach dem bisher gelesenen, dass XHTML ähnlich wie HTML erstellt wird, wobei u.a. strengere Maßstäbe an die Tags (öffnen/schließen) gestellt werden.
Gruß
moor

[suit]

Was ist

gerendert

guckst du hier: layout-engine

Was haben diese files mit XHTML zu tun?

sagte ich bereits - das hat nichts bzw nicht viel mit xhtml zu tun, das sind xml seiten die mit xsl in invalides html umgeformt werden (und das nicht sonderlich gut) - du darfst dir nicht denn quelltext der xml-ressource ansehen sondern den generierten quelltext im browser

die seite soll aber ansich nur zeigen, dass xml kein prinzipielles problem von modernen browsern ist oder html vorteile gegenüber xhtml bietet

im falle der wow-seite wird eben valides xml in invalides html umgeformt - das ist meiner ansicht nach weit schlechter als valides xhtml als text/html auszuliefern ;)

Ich dachte eigentlich nach dem bisher gelesenen, dass XHTML ähnlich wie HTML erstellt wird, wobei u.a. strengere Maßstäbe an die Tags (öffnen/schließen) gestellt werden.

ja, das ist auch richtig - genau aus dem grund ist es absolut problemlos möglich xhtml zu verwenden und es trotzdem als html parsen/darstellen zu lassen