Hallöchen,
wie siehtn des aus, ich dachte immer, der IE versucht zwar die stylesheets zu laden und zeigt sie dann einfach falsch an, aber auf meiner seite - aurachtaler.de - wird mir beim IE7 gar kein stylesheet angezeigt…
beim 8er wirds zumindest versucht (und dann die ‚kompatibilitätsansicht‘ vorgeschlagen, wenn man die aktiviert hat man das selbe resultat: gar kein stylesheet)… wird zwar nich alles perfect dargestellt (soweit ich mich erinnere) aber immerhin besser als gar kein style.
nach meinem letzten test bei validator.w3.org/unicorn sind stylesheet und xhtml valide… ideen, vorschläge, anregungen? - IE 6 muss nicht sein, aber wenn jmd weiß wie ich beim 7er zumindest den versuch erzwingen könnte, ETWAS hinzuzaubern… wäre ich dankbar
Die Seite verwendet offenbar XHTML (was der Validator testet),
wird aber als HTML (text/html) ausgeliefert, die browser
interpretieren die Seite also als fehlerhafte HTML-Markierungssuppe.
Bei HTML-Markierungssuppe ist es jedenfalls falsch, bei
inhaltsleeren Elementen wie link und meta eine Endmarkierung
() anzugeben, bei XHTML/XML hingegen neben der
Kurzschreibweise in Ordnung.
Da der MSIE bis Version 8 gar kein XHTML kann, wird der vermutlich
Schwierigkeiten mit den falschen Endmarkierungen haben und was
daraus für eine Fehlerbehandlung folgt, ist ein Geheimnis dieses
browsers, jedenfalls gibt es dafür kein definiertes Verhalten.
Fazit: Wenn man sich mit browsern nicht genau auskennt, so
verwendet man entweder XHTML und läßt es als XHTML
(application/xhtml+xml) ausliefern oder man verwendet HTML
und läßt es als HTML (text/html) ausliefern.
Eine Mischung XHTML als HTML ausliefern zu lassen, ist nur ein
Notbehelf für veraltete browser wie den MSIE bis Version 8.
Allerdings muß man sich dann mit der Fehlerbehandlung solcher
browser auskennen oder ersatzweise die Empfehlungen in der
XHTML1.0-Spezifikation beachten (nur selbstschließende
inhaltsleere Elemente verwenden in diesem Falle; zu beachten
gegebenenfalls auch die andere Interpretation des Inhaltes der
Elemente style und script, sofern verwendet).
aber, wenn ich die site als application/xhtml+xml ausliefere, zeigt mir der IE dann nicht den XML-Baum an? so wie im anhang mein ich? sry, kanns grad net probiern, das is nur mein ganz spontaner verdacht…
EDIT: ja ich weiß, is n blödes beispielbild, er kanns gar nich anders anzeigen, weils wirklich reines xml ist, aber is ja nur um zu verdeutlichen was ich mein
Schrieb ich ja schon, MSIE bis Version 8 kann kein XHTML, daher
sollte man dem keines senden, wenn man will, daß der was
interpretiert ;o)
Mag sein, daß Version 9 XHTML interpretieren kann, habe die
Vorschauversionen allerdings nicht ausprobiert.
Insofern, wenn man dem MSIE bis Version 8 etwas fehlerfreies
senden will, so muß dies wohl HTML sein und kein XHTML.
Wenn es einem egal ist, ob die Dokumente fehlerfrei sind, kann man
dem MSIE bis Version 8 natürlich auch das XHTML als HTML schicken
und sich auf eine brauchbare Fehlerbehandlung verlassen.
Dies erfordert aber mindestens die Beachtung des nicht
normativen Anhanges zu dem Thema bei der Spezifikation zu
XHTML1.0. Dort sind Hinweise zu finden, wie man das XHTML
hinschreibt, damit der HTML-Markierungssuppen-parser des MSIE
damit zurecht kommt, wenn man den Kram als text/html sendet,
wie bei dir geschehen - übrigens offenbar auch an browser, die
XHTML können. Diese interpretieren das dann natürlich ebenfalls
nur als fehlerhaftes HTML - also sinnlos, überhaupt XHTML zu
verwenden, wenn man es nie als XHTML aussendet. Da wäre es
besser, bei HTML4 zu bleiben.
Ich mache das jedenfalls so, daß das PHP-Skript Angaben des
browsers auswertet. Für die meisten browser wird dann XHTML
ausgeliefert, für netscape4 und solche, die sich dafür ausgeben,
wie der MSIE bis Version 8, wird das eben als HTML gesendet.
Das Dokument ist aber so konstruiert, daß der typische
HTML-Markierungssuppen-parser solch veralteter browser damit
zurechtkommt. Das liegt wiederum daran, daß eigentlich all diese
alten HTML-Markierungssuppen-parser grobe Fehler und Lücken
aufweisen, die dies erlauben. Korrekten HTML4-parsern könnte
man kein XHTML als HTML ausliefern, welches diese sinnvoll
anzeigen täten. Für solche müßte man das XHTML-Dokument zuvor
in ein HTML4-Dokument transformieren. Da es solche korrekt
funktionierenden HTML4-parsern mal abgesehen von den
Validatoren aber gar nicht gibt, die sowieso XHTML können, ergibt
sich da kein praktisches Problem, wenn man sich an die genannten
Empfehlungen hält.
soll ich das als fazit-empfehlung so auswerten, dass ich ebenfalls auf HTML 4.01 strict umsteigen sollte, weils einfach keine möglichkeit gibt, valides xhtml hinzuzaubern und es mit diversen tricks auch für den IE anzeigbar zu machen?..
-.-’ wie ich dieses schrottteil hasse…
alternative wäre damit zu leben und bei xhtml zu bleiben…
hmmm stolz überwinden?? …
mal sehn…
Wie schon gesagt, weil du das offenbar immer als text/html
ausliefern läßt und nicht als application/xhtml+xml, wird das von
keinem browser als korrektes XHTML interpretiert.
Wenn du deine Dokumente immer als text/html ausliefern läßt,
egal an welchen browser, solltest du in der Tat konsequent sein und
HTML4 verwenden und nicht XHTML.
Sendest du den Kram an Opera, Geckos, webKit, Amaya etc als
application/xhtml+xml und an MSIE <9, netscape4 etc als text/html,
so solltest du das dafür sinnvoll notieren, also
statt und
statt etc
Das ist ja beides korrektes XHTML, nur die zweite, von dir
verwendete Variante ist inkompatibel zu den alten
HTML-Markierungssuppen-parsern.
Mit der ersten Variante kommen die
HTML-Markierungssuppen-parser klar,
weil die als inhaltsleeres interpretieren und nicht
anhand der in HTML4 theoretisch erlaubten Kurzsyntax.
kann hingegen die Programme ins Schleudern
geraten lassen, weil die HTML-Markierungssuppen-parser wissen,
daß link ein inhaltsleeres Element ist und dann zu spekulieren
beginnen, was bedeuten könnte, während sie das
/ bei einfach ignorieren (was falsch für HTML4 ist,
aber günstig für den Wunsch, das XHTML als HTML ausliefern zu
wollen ;o)
Man kann relativ problemlos korrektes XHTML schreiben, welches
der MSIE sinnvoll als HTML interpretieren kann. Sinnvoll bedeutet
dabei nicht, daß das dann auch formal korrektes HTML wäre, das
bedeutet nur, daß die Fehler im Dokument durch Fehler oder
Lücken oder Eigenheiten aller HTML-Markierungssuppen-parser
kompensiert werden, so daß sie nicht weiter stören.
Neben den Besonderheiten bei inhaltsleeren Dokumenten sollte
man dann nur darauf verzichten, in style und script etwa Konstrukte
zu verwenden, die spezifisch für eine Sprachvariante sind, besser
man verweist dann gleich immer auf externe Dateien, um das
Problem zu umgehen, statt das im selben Dokument zu notieren.
Allerdings fallen dem Validator Mängel auf, wenn in einem
XHTML-Dokument in style oder script mangelhaft maskiertes Zeug
steht, wie es in HTML möglich ist. Sollte das der Fall sein, kann man
das allerdings nicht einfach korrigieren, wenn man den Kram auch
noch alternativ als text/html senden will, dann muß man auf jeden
Fall den Inhalt dieser Elemente auslagern.
die meisten Browser senden im http header in der Accept zeile „application/xhtml+xml“ wenn sie XHTML unterstützen. Der IE tut das demnach also nicht. Und im gegnzug zum User-Agent, ist die Accept Zeile eine die eher selten modifiziert wird und man sie deshalb durchaus als zuverlässig betrachten darf.
Jedenfalls nutze ich diese immer um zu ermitteln ob der client XHTML haben soll, oder doch lieber text/html.
Das nutze ich auch unter anderem, gucke dann der Reihe nach
durch nach application/xhtml+xml, application/xml und text/xml
und text/html.
Ich meine, netscape4 und MSIE bis Version 8 geben da nicht einmal
explizit an, daß sie text/html kennen/akzeptieren.
Andererseits geben praktisch alle browser an, daß sie /
akzeptieren, also eigentlich alles ;o)
Die goggle-Bots sind auch so ein Problemfall, der nichts angibt.
Nach meinem Eindruck bevorzugt der aber text/html oder
zumindest bewertet goggle application/xhtml+xml schlechter und
man bekommt weniger Zulauf über goggle, wenn man den Bots
das unterschiebt.
Daher schalte ich hinter die Analyse der explizit akzeptierten
Formate noch eine weitere, die versucht herauszubekommen, ob es
sich um einen google-Bot handelt oder um einen ‘Mozilla4’ -
also netscape4 oder MSIE bis Version 8, da gehe ich davon aus,
daß die hinsichtlich XHTML nur Bahnhof verstehen und die
bekommen das dann als HTML serviert ;o)
Ansonsten bekommen Programme, die keine Angaben zu
bevorzugten Formaten aus obigem Sortiment machen eben
XHTML serviert. Wenn mir da jetzt weitere Indizien bekannt
werden, die etwas anderes für ein bestimmtes Programm
nahelegen, täte ich das gegebenenfalls auch ergänzen.
Ein spezieller Validator (für mobile Geräte, empfiehlt die
Verwendung von XHTML) hat auch nicht application/xhtml+xml
explizit angegeben, aber text/html und hat deshalb den Kram
auch als HTML bekommen, hat dann aber in seinem Ergebnis
bemängelt, daß da was nicht zusammenpaßt und er das lieber als
XHTML gehabt hätte - weiß ich auch, aber wenn der keine
vernünftigen Informationen sendet, wie soll das Skript dann
herausfinden, was am hilfreichsten ist ;o)
Solange da nicht alle Programme sinnvolle Angaben machen,
zumindest sinnvoller als /, bleibt das letztlich ein heiteres Raten.
langsam wirds kompliziert^^ prinzipiell hab ich schon verstanden wie du das meinst, aber wie setzt du das mit php (nehm ich an) um?
hast du ein kleines beispielscript oder so, das zeigt, wie du die unterschiedlichen typen trennst und dann (nehme ich wieder mal an) per header(’’); rausschmeißt…?
Bei meinem minimalen Projekt (schon einige Jahre alt) steht so
ein Skript mit drin: hoffmann.bplaced.net/minimal/ind … rojektkopf
(dritter Quelltext-Einschub … ‘header fuer xhtml senden?’)
Je nachdem, welche Philosophie man da verfolgt, wie verständlich
oder elegant man das machen will, kann es da aber zahlreiche
Varianten geben.
Wobei ich gerade sehe, daß ich da die Information zu encoding
auch mal direkt mit zum Format schreiben sollte, wie ich das bei
anderen Projekten längst gemacht habe ;o)
langsam wirds kompliziert^^ prinzipiell hab ich schon verstanden wie du das meinst, aber wie setzt du das mit php (nehm ich an) um?
