nicht angemeldet
suit
molily
Der Martin
Der Martin
molily
molily
Gunnar Bittersmann
Bei meinem CMS achte ich darauf, dass alle Ausgaben XHTML 1.1-konform sind. Auch arbeite ich konsequent mit UTF-8.
Jetztz stellt sich mir die Frage, wie ich den Content-Type im HTML-Header angeben soll.
Richtig wäre ja application/xhtml+xml, was aber dummerweise im IE7 immer noch nicht funktioniert.
Würde es vom ästhetischen/technischen Standpunkt aus Sinn machen, dem IE (und jedem Browser, der sich dafür ausgibt), text/html zu senden und allen anderen, die es richtig können, application/xhtml+xml?
Der FF interpretiert das XHTML ja auch bei text/html richtig, aber geht dabei ja von XHTML 1.0 aus, wenn ich mich nicht irre.
Würde mich mal interessieren, wie ihr sowas handhabt. Git ja immer mehrere Wege nach Rom ;)
Bei meinem CMS achte ich darauf, dass alle Ausgaben XHTML 1.1-konform sind. Auch arbeite ich konsequent mit UTF-8.
xhtml 1.1 solltest du nur verwenden, wenn du WIRKLICH genau weisst, was du tust- ggf. wäre eine "rückschritt" zu xhtml 1.0 strict interessanter
Jetztz stellt sich mir die Frage, wie ich den Content-Type im HTML-Header angeben soll.
application/xml bzw application/xhtml+xml
und das idealerweise nicht im html-head-bereich sondern im http-header
Würde es vom ästhetischen/technischen Standpunkt aus Sinn machen, dem IE (und jedem Browser, der sich dafür ausgibt), text/html zu senden und allen anderen, die es richtig können, application/xhtml+xml?
xhtml 1.1 nicht als xml zu verarbeiten ist pervers ;)
Der FF interpretiert das XHTML ja auch bei text/html richtig, aber geht dabei ja von XHTML 1.0 aus, wenn ich mich nicht irre.
nein, der browser "geht davon aus" was du ihm schickst, wenn im doctype html 4.01 transitional angegen ist, geht er davon aus, wenn dort xhtml 1.0 strict steht hiervon ;)
Würde mich mal interessieren, wie ihr sowas handhabt. Git ja immer mehrere Wege nach Rom ;)
xhtml 1.0 transitional oder strict (je nach anforderung) als text/html verschickt (konsequent an jeden browser) da die verbreitung von echten, vernünftigen xml-browser noch zu klein ist und keine maßgeblichen vorteile bietet
als application/xhtml+xml wirds dann verschickt, wenn das ganze für andere lesegeräte versandt wird (zb flash-files, die informationen aus dem xhtml-file beziehen
und das idealerweise nicht im html-head-bereich sondern im http-header
Schreibfehler von mir, ich meinte natürlich den HTTP-Header ;)
Diese Metatags im HTML-Head nutze ich nie, weils nicht nötig ist IMO, wenn der HTTP-Header passt.
xhtml 1.1 nicht als xml zu verarbeiten ist pervers ;)
Praktisch nicht mehr und nicht weniger als XHTML 1.0. Jedes XHTML-1.1-Dokument ist ein gültiges XHTML-1.0-Dokument, bis auf wenige Ausnahmen könnte man auch in XHTML 1.1 die Kompatibilitätsrichtlinien umsetzen, sofern sie heutige User-Agents noch betreffen.
Praktisch sind die Hürden gering, es ist eher eine theoretische Frage: XHTML 1.1 ist ein Beispiel für eine echte XML-Anwendung mit XHTML Modularization. Eine Kompatibilität mit HTML-Tag-Soup-Parsern war nie vorgesehen. Auch wenn neuere XHTML-1.1-Spezifikationen plötzlich auch den MIME-Typ text/html zulassen - Sinn und Zweck des Unternehmens war das nicht, und eine vollständige Kompatibilität mit HTML-Tag-Soup-Browsern wie bei XHTML 1.0 kann auch nicht erreicht werden, dazu gibt es im Detail einige Unterschiede.
Mathias
@@molily:
Jedes XHTML-1.1-Dokument ist ein gültiges XHTML-1.0-Dokument
Nein. Es gibt keine Ruby-Annotationen in XHTML 1.0.
Auch wenn neuere XHTML-1.1-Spezifikationen plötzlich auch den MIME-Typ text/html zulassen
Problematisch an XHTML 1.1 als text/html ist u.a., dass es unmöglich ist, die Textverarbeitungssprache anzugeben: das 'lang'-Attribut existiert nicht, das 'xml:lang'-Attribut wird von Tagsoup-Parsen nicht beachtet. [Ishida]
Live long and prosper,
Gunnar
Jedes XHTML-1.1-Dokument ist ein gültiges XHTML-1.0-Dokument
Nein. Es gibt keine Ruby-Annotationen in XHTML 1.0.
Du hast natürlich Recht, aber du hast die Aussage aus dem Kontext gerissen. Nicht umsonst habe ich im Satz vorher und im Satz nachher »praktisch« betont, d.h. die XHTML-1.1-Dokumente, die so geschrieben werden, nutzen diese Features äußerst seltenst, sondern bieten nicht viel mehr oder weniger als XHTML 1.0 (Ausnahmen hast du genannt).
Mathias
@@molily:
Nein. Es gibt keine Ruby-Annotationen in XHTML 1.0.
[…] die XHTML-1.1-Dokumente, die so geschrieben werden, nutzen diese Features äußerst seltenst
Ruby-Annotationen wären so ziemlich der einzige Grund, XHTML 1.1 einzusetzen. Demzufolge nutzen die XHTML-1.1-Dokumente, bei denen XHTML 1.1 auch sinnvoll ist, diese Features äußerst oft. ;-)
Live long and prosper,
Gunnar
Hallo,
Würde es vom ästhetischen/technischen Standpunkt aus Sinn machen, dem IE (und jedem Browser, der sich dafür ausgibt), text/html zu senden und allen anderen, die es richtig können, application/xhtml+xml?
klingt nicht ungeschickt - aber woran willst du einen IE auf HTTP-Ebene erkennen? Am User-Agent-Header? Der ist ja beliebig manipulierbar; wenn jemand das möchte, kann sich der IE als alles mögliche ausgeben.
Und dann bekäme er plötzlich application/xhtml+xml und wird den User fragen, wo er denn diese Datei speichern soll.
So long,
Martin
klingt nicht ungeschickt - aber woran willst du einen IE auf HTTP-Ebene erkennen? Am User-Agent-Header?
Genau daran. Und dabei bin ich mir über die "Gefahren" im klaren. Andere Möglichkeiten gibts ja nicht, soweit ich informiert bin.
wenn jemand das möchte, kann sich der IE als alles mögliche ausgeben.
Und dann bekäme er plötzlich application/xhtml+xml und wird den User fragen, wo er denn diese Datei speichern soll.
Dann muss ich aber sagen, selber schuld. Ich mein wenn ich auf nen Golf nen Mercedes-Stern klebe, wird ja immer noch kein Auto draus ;)
Ich würde jetzt aber mal davon ausgehen, wer dem IE sagt, dass er sich als Opera oder Firefox ausgeben soll, der weiss auch, wieso er dann eine solche Seite zum Download angeboten bekommt.
Servus,
klingt nicht ungeschickt - aber woran willst du einen IE auf HTTP-Ebene erkennen? Am User-Agent-Header? Der ist ja beliebig manipulierbar; wenn jemand das möchte, kann sich der IE als alles mögliche ausgeben.
Ohne über Sinn und Unsinn der Vorgehensweise streiten zu wollen (in dem Fall tendiere ich zu Unsinn ;) - wer wissentlich seinen Browser als etwas anderes ausgibt, als er ist, ist selbst Schuld, wenn Anwendungen nicht funktionieren.
Gruss
Patrick
Hallo,
woran willst du einen IE auf HTTP-Ebene erkennen? Am User-Agent-Header? Der ist ja beliebig manipulierbar; wenn jemand das möchte, kann sich der IE als alles mögliche ausgeben.
Ohne über Sinn und Unsinn der Vorgehensweise streiten zu wollen (in dem Fall tendiere ich zu Unsinn ;)
du magst es für Unsinn halten - ich fand es vor einigen Jahren sogar sehr sinnvoll. Ich habe nämlich damals versucht, in der MS Knowledge Base und anderen Info- und Dokuseiten des Konzerns Informationen zu finden. Mit einem IE, bei dem JS und ActiveX abgestellt sind, erschien das nahezu unmöglich. Es wimmelte von Darstellungsfehlern und unbenutzbaren Seiten ohne Navigationselemente.
Bis man den IE als etwas anderes ausgibt. Dann bekommt er plötzlich Seiten ausgeliefert, die auch ohne JS nutzbar sind und sowas wie ActiveX nicht im Entferntesten nötig haben.
wer wissentlich seinen Browser als etwas anderes ausgibt, als er ist, ist selbst Schuld, wenn Anwendungen nicht funktionieren.
Ja, denn er sollte wissen, was er tut.
Schönen Tag noch,
Martin
du magst es für Unsinn halten - ich fand es vor einigen Jahren sogar sehr sinnvoll.
Browser wie Opera haben das lange gemacht und machen es immer noch direkt und indirekt in Form von JavaScript-Fixes, mit denen gewisse Objekte überschrieben werden, damit Anwendungen funktionieren, weil sie schlechte Browserweichen beinhalten. Meines Wissens hat Safari auch so etwas.
Mathias
Der FF interpretiert das XHTML ja auch bei text/html richtig, aber geht dabei ja von XHTML 1.0 aus, wenn ich mich nicht irre.
Was meinst du damit, dass er von XHTML 1.0 ausgeht?
Firefox setzt alles, was er als text/html kommt, dem fehlertoleranten Tag-Soup-Parser vor. Der legt nicht die strengen Regeln irgendeines Standards (XML- und XHTML-Syntax) an, sondern versucht im Zweifelsfall irgendwie mit Heuristik einen DOM-Baum aus dem Markup zu bauen. Technisch gesehen kommt diese Parser mit (validen, im Sinne der Richtlinien abwärtskompatiblen) XHTML-Dokumenten genauso gut klar wie mit (validen) HTML-4-Dokumenten.
Eine Verarbeitung als XML und XHTML erreicht man nur mit den entsprechenden Content-Types.
Mathias
Eine Verarbeitung als XML und XHTML erreicht man nur mit den entsprechenden Content-Types.
Ich weiss, deshalb habe ich dieses Thema zur Diskussion gestellt. Mich würde auch genau deshalb interssieren, ob mein Ansatz sinnvoll ist oder nicht.
Aber danke, dass du meine Aussagen bestätigst, auch wenns nicht wirklich nötig gewesen wäre :)
Bei meinem CMS achte ich darauf, dass alle Ausgaben XHTML 1.1-konform sind.
Warum eigentlich?
Jetztz stellt sich mir die Frage, wie ich den Content-Type im HTML-Header angeben soll.
Richtig wäre ja application/xhtml+xml, was aber dummerweise im IE7 immer noch nicht funktioniert.
Würde es vom ästhetischen/technischen Standpunkt aus Sinn machen, dem IE (und jedem Browser, der sich dafür ausgibt), text/html zu senden und allen anderen, die es richtig können, application/xhtml+xml?
Lies dir mal bitte http://schneegans.de/web/xhtml/ durch, insbesondere den Absatz "Content Negotiation" unter "XHTML 1.0 oder 1.1?"
Und auch wenn molily anderer Meinung ist als das W3C, hier dessen Empfehlungen: http://www.w3.org/TR/xhtml-media-types/#summary
Gruß Gunther
Und auch wenn molily anderer Meinung ist als das W3C, hier dessen Empfehlungen: http://www.w3.org/TR/xhtml-media-types/#summary
?? Bin ich gar nicht.
Mathias
Hi Mathias!
Und auch wenn molily anderer Meinung ist als das W3C, hier dessen Empfehlungen: http://www.w3.org/TR/xhtml-media-types/#summary
?? Bin ich gar nicht.
Sorry, bin gerade etwas neben der Spur.
Dann habe ich dein Posting missverstanden, bzw. fehlinterpretiert.
Nehme natürlich alles zurück und behaupte das Gegenteil! ;-)
Gruß Gunther
@@Mega:
Bei meinem CMS achte ich darauf, dass alle Ausgaben XHTML 1.1-konform sind.
Das ist weitgehend sinnfrei. Wenn nicht spezielle Gründe für XHTML 1.1 sprechen, sprechen unzählige Gründe dagegen. Verwende besser XHTML 1.0 Strict.
Würde es vom ästhetischen/technischen Standpunkt aus Sinn machen, dem IE (und jedem Browser, der sich dafür ausgibt), text/html zu senden und allen anderen, die es richtig können, application/xhtml+xml?
Nein. Wenn du unterschiedlich ausliefern willst, dann nicht danach, ob IE oder nicht, sondern danach, ob der Client application/xhtml+xml akzeptiert oder nicht: Accept, content negotiation.
Live long and prosper,
Gunnar
Das ist weitgehend sinnfrei. Wenn nicht spezielle Gründe für XHTML 1.1 sprechen, sprechen unzählige Gründe dagegen. Verwende besser XHTML 1.0 Strict.
Was heisst "weitgehend"?
Meine Entscheidung zu XHTML 1.1 ist bisher lediglich, mir möglist viele Möglichkeiten offen zu halten.
Nein. Wenn du unterschiedlich ausliefern willst, dann nicht danach, ob IE oder nicht, sondern danach, ob der Client application/xhtml+xml akzeptiert oder nicht: Accept, content negotiation.
Stimmt, daran hab ich gar nicht gedacht. Browserr sind doch eigentlich recht gesprächig, wenn man weiss, wie ;)
Allerdings stellt sich doch die eigentlichen Frage immer, da XHTML 1.0 strict ja ebenfalls als application/xhtml+xml ausgeliefert werden sollte, oder irre ich mich da jetzt?
Letztendlich geht es mir ja um die Frage des ausgelieferten Content-Types bei der Verwendung von XHTML (und später evtl. XML), unabhängig von der Version.
@@Mega:
Meine Entscheidung zu XHTML 1.1 ist bisher lediglich, mir möglist viele Möglichkeiten offen zu halten.
Im Gegenteil: mit XHTML 1.1 schließt du viele Möglichkeiten aus. Eine hatte ich bereits genannt; eine weitere ist die Verwendung von Imagemaps.
Weitere siehe Archiv.
Live long and prosper,
Gunnar
Im Gegenteil: mit XHTML 1.1 schließt du viele Möglichkeiten aus.
Was ich bisher so recheriert hab, ist das sogar einiges.
Mal sehen, dann werd ich wohl doch XHTML1.0 strict nutzen, dürfte aktuell ohne Quelltextänderung funktionieren.
Die Methode zum auswählen des Content-Types nehm ich dann auch heute in Angriff.
Orientierungsfrei, planfrei, glückfrei, hirnfrei, selbstfrei, kopffrei, atemfrei, sang- und klangfrei,
sinnfrei
Autsch! Petition!
(Es ist zweckfrei. Ich bin machtfrei.)
