Welche Browser kennen/verarbeiten kein application/xhtml+xml?

[Daniel unreg]

Hallo,

wenn man vom offensichtlichen absieht (Internet Explorer), welche Browser können XHTML, welches mit dem MIME Typ "application/xhtml+xml" versendet wird, nicht verarbeiten?

Ich musste leider feststellen, dass Lynx (2.8.3nochwas) Dateien, die mit dem genannten Typ versendet werden, ebenfalls herunterladen möchte.

Nun habe ich etwas von meinem XHTML-Enthusiasmus verloren. Wird es also aus der Sicht des Bereichs Zugänglichkeit immer sinnlos sein, XHTML als application/xhtml+xml zu versenden (selbst wenn es der IE mal kann)?

Oder ist Lynx ein inzwischen veralteter Browser (habe lange kein Update gesehen) und andere Textbrowser (kenne leider keine anderen) können mit XHTML umgehen. Oder stellt die XML-Basis von XHTML ein zu großes Problem für diese Browser dar?

Gruß;

[Mathias Brodala]

Hallo Daniel.

wenn man vom offensichtlichen absieht (Internet Explorer), welche Browser können XHTML, welches mit dem MIME Typ "application/xhtml+xml" versendet wird, nicht verarbeiten?

Am besten beschränkst du dich bei der Entscheidung, ob ein Dokument mit application/xhtml+xml oder text/html ausgeliefert werden soll auf die Auswertung des HTTP-Accept-Headers. Meint ein Client application/xhtml+xml zu verstehen, wird er dies dort auch angeben.

Oder ist Lynx ein inzwischen veralteter Browser (habe lange kein Update gesehen) und andere Textbrowser (kenne leider keine anderen) können mit XHTML umgehen. Oder stellt die XML-Basis von XHTML ein zu großes Problem für diese Browser dar?

Lynx ist keineswegs veraltet und hat auch heute noch eine Daseinsberechtigung. Die verbesserte Variante, Links, sendet zwar wie der IE in besagtem Header „*/*“, kann aber im Gegensatz zu diesem wirklich application/xhtml+xml verarbeiten.

Einen schönen Donnerstag noch.

Gruß, Mathias

[Daniel unreg]

Hallo Mathias,

Am besten beschränkst du dich bei der Entscheidung, ob ein Dokument mit application/xhtml+xml oder text/html ausgeliefert werden soll auf die Auswertung des HTTP-Accept-Headers. Meint ein Client application/xhtml+xml zu verstehen, wird er dies dort auch angeben.

Ja, daran dachte ich bereits. Seltsamerweise war ich bis eben der Meinung, davon werde abgeraten. Anscheinend habe ich meine Quelle (Schneegans' Einmaleins) noch immer nicht genau genug gelesen.

Lynx ist keineswegs veraltet und hat auch heute noch eine Daseinsberechtigung. Die verbesserte Variante, Links, sendet zwar wie der IE in besagtem Header „*/*“, kann aber im Gegensatz zu diesem wirklich application/xhtml+xml verarbeiten.

Kann Links denn auch die Zeichenkodierung im Meta-Tag erkennen, wenn dort für content-type application/xhtml+xml angegeben wird?

Schönen Karfreitag.

Gruß;

[Mathias Brodala]

Hallo Daniel.

Lynx ist keineswegs veraltet und hat auch heute noch eine Daseinsberechtigung. Die verbesserte Variante, Links, sendet zwar wie der IE in besagtem Header „*/*“, kann aber im Gegensatz zu diesem wirklich application/xhtml+xml verarbeiten.

Kann Links denn auch die Zeichenkodierung im Meta-Tag erkennen, wenn dort für content-type application/xhtml+xml angegeben wird?

Was hat das eine mit dem anderen zu tun? Und warum sollte kein Content-Type-Header vom Server gesendet werden? Diesen wertet Links auf jeden Fall aus.

Einen schönen Freitag noch.

Gruß, Mathias

[Daniel unreg]

Hallo Mathias,

Was hat das eine mit dem anderen zu tun? Und warum sollte kein Content-Type-Header vom Server gesendet werden? Diesen wertet Links auf jeden Fall aus.

Das eine hat tatsächlich nichts mit dem anderen zu tun. Wenn ich den Accept-Header auswerte werde ich auch die entsprechende Kodierung mitsenden. Ich bezog mich jetzt aber auf andere Fälle, z.B. wenn das Dokument lokal geöffnet wird, also kein Header verfügbar ist.

Gruß;

[Mathias Brodala]

Hallo Daniel.

Was hat das eine mit dem anderen zu tun? Und warum sollte kein Content-Type-Header vom Server gesendet werden? Diesen wertet Links auf jeden Fall aus.

Das eine hat tatsächlich nichts mit dem anderen zu tun. Wenn ich den Accept-Header auswerte werde ich auch die entsprechende Kodierung mitsenden. Ich bezog mich jetzt aber auf andere Fälle, z.B. wenn das Dokument lokal geöffnet wird, also kein Header verfügbar ist.

In diesem Falle wird der Quelltext angezeigt, sofern dies nach einem Dialog so festgelegt wurde. Der Inhalt des meta-Elementes wird hier also offenbar nicht berücksichtigt.

Einen schönen Freitag noch.

Gruß, Mathias

[Daniel unreg]

Hallo Mathias,

In diesem Falle wird der Quelltext angezeigt, sofern dies nach einem Dialog so festgelegt wurde. Der Inhalt des meta-Elementes wird hier also offenbar nicht berücksichtigt.

Verstehe. Ich habe nun eine Windows-Version von Links gefunden und werde ihn mir mal ansehen.

Vielen Dank für deine Mühe.

Gruß;

[D.R.]

Hallo,

Am besten beschränkst du dich bei der Entscheidung, ob ein Dokument mit application/xhtml+xml oder text/html ausgeliefert werden soll auf die Auswertung des HTTP-Accept-Headers. Meint ein Client application/xhtml+xml zu verstehen, wird er dies dort auch angeben.

Das ist ja alles ganz schön und gut, aber so lange man seine Seite so ausliefert, muss man immer darauf achten, dass man sein XHTML möglichst HTML-kompatibel schreibt, was den Verzicht auf so tolle Features wie:

„~~~xml Der Quelltext sieht folgendermaßen aus:
<pre><![CDATA[<a href="foo">bar</a>]]></pre>

  
oder  
  
„`<script type="text/javascript" src="foo.js" />`{:.language-xml}“  
  
…verzichten muss, weil man die Tag-Soup-Parser sonst durcheinander bringen würde.  
  
Ich verstehe einfach nicht, warum das wesentlich komplizierter zu parsende HTML so gut unterstützt wird, während das einfachere XHTML nicht von jedem Browser verstanden wird.  
  
mfg. Daniel

-- 
[Experten raten von der Verwendung des Internet Explorers ab!](http://web.oesterchat.com/internet-explorer/)  
[Mein SELF-stylesheet](http://danielrichter.da.funpic.de/SELFForumsCSS.html) | [Darum Firefox!](http://www.firefox-love.de/)  
[Selfcode](http://forum.de.selfhtml.org/cgi-bin/selfcode.pl): [ie:{ fl:( br:> va:) ls:& fo:) rl:( n4:# ss:| de:> js:) mo:} zu:}](http://www.peter.in-berlin.de/projekte/selfcode/?code=ie%3A%7B+fl%3A%28+br%3A%3E+va%3A%29+ls%3A%26+fo%3A%29+rl%3A%28+n4%3A%23+ss%3A%7C+de%3A%3E+js%3A%29+mo%3A%7D+zu%3A%7D)

[Daniel unreg]

Hallo,

Ich verstehe einfach nicht, warum das wesentlich komplizierter zu parsende HTML so gut unterstützt wird, während das einfachere XHTML nicht von jedem Browser verstanden wird.

Hast du nicht das Buch "Monopole für Dummies" gelesen? </ironie>

Der Stillstand ist zwar jetzt vorbei, aber Internet Explorer 8 (oder "next") wird vermutlich noch immer kein XHTML kennen.

Ende April soll es aber eine Vorschau der Version auf einer Messe geben, mal sehen, was uns da so präsentiert wird. Eventuell hat die große Nachfrage auf application/xhtml+xml doch etwas gebracht.

Gruß;

[D.R.]

Hallo,

Der Stillstand ist zwar jetzt vorbei, aber Internet Explorer 8 (oder "next") wird vermutlich noch immer kein XHTML kennen.

Waas?! Also dann geht mir der IE wirklich am A**** vorbei. Dass µ$oft zu IE7-Zeiten noch ein Wenig warten wollte (weil sie's ja unbedingt 100% richtig implementieren wollen) habe ich ja verstanden. Aber vom IE8 erwarte ich jetzt endlich ordentliche XHTML-Fähigkeiten.

Eventuell hat die große Nachfrage auf application/xhtml+xml doch etwas gebracht.

Da hoffe ich. Ich frage mich, was so schwer daran ist, einen XML-Parser so umzubauen, dass er den XHTML-Namespace verarbeiten kann.

mfg. Daniel

[Daniel unreg]

Hallo,

Waas?! Also dann geht mir der IE wirklich am A**** vorbei. Dass µ$oft zu IE7-Zeiten noch ein Wenig warten wollte (weil sie's ja unbedingt 100% richtig implementieren wollen) habe ich ja verstanden. Aber vom IE8 erwarte ich jetzt endlich ordentliche XHTML-Fähigkeiten.

"We don't want to do a half-formed job of XHTML support", Wilson said. He did note that Microsoft is testing a parser and experimenting with integrating multiple schema, however.

Das ganze bezog sich auf IE.Next.

Warum man einen neuen Parser benötigt, obwohl IE schon seit v5.0 XML verarbeiten kann ist allerdings eine berechtigte Frage.

Gruß;

[molily]

Hallo,

Ende April soll es aber eine Vorschau der Version auf einer Messe geben, mal sehen, was uns da so präsentiert wird. Eventuell hat die große Nachfrage auf application/xhtml+xml doch etwas gebracht.

Äh, wat, große Nachfrage?

Ernsthaft, für diese XHTML-Unterstützung interessiert sich ein extrem winziger Teil der Webautoren, und das auch eher zum Selbstzweck ("Der IE hat gefälligst die Standards zu unterstützen!"). Dass die IE-Programmierer keine Zeit verschwenden, um ein Feature einzubauen, dass in der Praxis keine nennenswerten Vorteile bringt, kann ich verstehen. Außerdem geht der Trend momentan sowieso weg von XHTML. Die Kehrtwende des W3Cs (Gründung einer neuen HTML-Arbeitsgruppe, die eben nicht auf XML, sondern auf die Standardisierung von Tag-Soup-Parsing setzt) wurde zum großen Teil durch den Druck der Webstandards-Community angestoßen - in der spricht niemand mehr von XHTML, viele sind demonstrativ zu Tag Soup zurückgekehrt und sowieso kommen die wenigsten auf die Idee, XHTML als application/xhtml+xml auszuliefern. Selbst hierzulande sagen XHTML-Enthusiasten, dass sich das einfach nicht lohnt. Also, wo ist die große Nachfrage? Wo lecken sich die Webautoren die Finger nach XHTML?

Wir können das jahrelange elendige Klagen darüber, dass IE kein XHTML kann, auch einfach einstellen. Vielleicht wird IE es nie können, und trotzdem wird es in der Praxis niemanden jucken. Oder wird das Leben mit application/xhtml+xml denn so unglaublich besser? Es ist höchstens ein kleiner Baustein zur Umsetzung des riesigen W3C-XML-Frameworks - und zu dessen Implementierung wird es höchstwahrscheinlich nie kommen. Das W3C fährt zwar noch eine Doppelstrategie, es gibt noch die XHTML-2-Arbeitsgruppe sowie XForms, XFrames, XML Events, RDF/GRDDL usw. usf., aber da tut sich ebenso nichts. Ich habe auch den Eindruck, dass sich die wenigsten überhaupt noch dafür interessieren. Ich denke nicht, dass darin die Zukunft liegt.

Mathias

[Daniel unreg]

Hallo,

Äh, wat, große Nachfrage?

Du hast ja recht.

Nachdem jetzt klar wurde, dass HTML 5.2 nur standardisiert, was auch außreichend (d.h IE6-7 mäßig) implementiert ist: Wen interessierts?

Abschied;

[Daniel Thoma]

Hallo molily,

Die Kehrtwende des W3Cs (Gründung einer neuen HTML-Arbeitsgruppe, die eben nicht auf XML, sondern auf die Standardisierung von Tag-Soup-Parsing setzt) wurde zum großen Teil durch den Druck der Webstandards-Community angestoßen - in der spricht niemand mehr von XHTML, viele sind demonstrativ zu Tag Soup zurückgekehrt und sowieso kommen die wenigsten auf die Idee, XHTML als application/xhtml+xml auszuliefern. Selbst hierzulande sagen XHTML-Enthusiasten, dass sich das einfach nicht lohnt. Also, wo ist die große Nachfrage? Wo lecken sich die Webautoren die Finger nach XHTML?

Wenn der XML-Weg tatsächlich beerdigt würde zu Gunsten eines weiterwurstelns im Tag-Soup-Stil, würde das wohl im wesentlichen bedeuten, dass man das Web gegen Microsoft eben nicht weiter entwickeln kann. Was der IE kann, ist nach wie vor das, was man in der Praxis einsetzen kann, für die anderen Browserhersteller entsteht dadurch auch gar kein Bedarf mehr, groß über HTML 4 und CSS 2 hinauszudenken, folglich tut es eigentlich auch keiner.

Das Ziel von XHTML war es nicht, das Leben der Webautoren leichter zu machen (HTML 4 ist ja erstmal genau so einfach). Das Ziel war, HTML auf eine aufgeräumte, wohldefinierte Basis zu stellen und damit die Weiterentwicklung und die Implementierung zu vereinfachen.
Viele der vom W3C entwickelten Standards waren auch ein Erfolg, nur nicht im Web. XML hat sich als Datenaustauschformat praktisch überall etabliert, XSLT und XSchema finden breite Verwendung, selbst RDF wird meines Wissens mittlerweile von Oracle unterstütz (und dann wahrscheinlich auch von anderen großen DBs), SVG ist ein durchaus brauchbares Vektorgrafikformat geworden, selbst das viel gescholtene XForms hat in OpenOffice Einzug in die Praxis erhalten.
Nur im Web sieht man nichts davon oder bestenfalls auf der Serverseite.
Gerade dieses Ziel, eine saubere Grundlage für die Weiterentwicklung zu bekommen, wurde durch die Weigerung von MS, XHTML richtig zu unterstüzen, verhindert.

Ich sehe auch nicht, was die Rückkehr zu einer Tag-Soup bringen soll.
XML bietet Erweiterungsmöglichkeiten, bei Tag-Soup wird man wahrscheinlich wieder zu Bastellösungen gezwungen sein (Micro-Formate und so Kram).

Ich habe den Eindruck, dass zur Zeit einfach wieder Konzeptlosigkeit angesagt ist und man am liebsten alles standardisieren will, was sich irgendjemand nebenbei ausgedacht hat, um ein konkretes Problem zu lösen.
Quasi eine Renaissance der Layer- und Fonttag-Phase.
Die zu erwartende Gegenbewegung zum Validator- und "Semantik"-fanatismus, der hier früher angesagt war.
Seit man mit HTML und JS halbwegs dynamische Anwendungen bauen kann, scheint wieder eine gewisse Goldgräberstimmung zu herrschen, bei der der erzielte Effekt zählt und sich kaum jemand dafür interessiert, das Medium technisch tragfähig weiter zu entwickeln. Das W3C tut gut daran, auf diese Entwicklungen zu beachten, aber sollte sich davon nicht vereinnahmen lassen. Seine Aufgabe ist es, die technischen Grundlagen für das Web langfristig zu entwickeln und nicht die Bedürfnisse von hippen Web 2.0 Diensten zu erfüllen.

Vielleicht vernachlässigen die bisherigen XHTML 2-Entwürfe die Bedürfnisse von nicht-Profis zu sehr und es ist sicher sinnvoll darüber nachzudenken, wie man weiterhin einen halbwegs breiten Zugang zum Web ermöglichen kann.
Deswegen jetzt der gewachsene Konzeptlosigkeit den Segen als W3C-Empfehlung zu geben halte ich für den falschen Weg.

Die technische Entwicklung des Web scheint mir nicht im Wesentlichen durch ein verschlafenes W3C gebremst zu werden, sondern nach wie vor durch mangelnde Konkurrenz auf dem Browsermarkt. Es ist ja nicht so, dass die neuen Standards von Webautoren abgelehnt worden wären, sie sind dort bislang erst gar nicht angekommen.

Grüße

Daniel

[Tim Tepaße]

Hallo Daniel,

ein kleiner Einwurf nur zum Thema Syntax:

... eines weiterwurstelns im Tag-Soup-Stil ...
... Konzeptlosigkeit ...
... der gewachsene Konzeptlosigkeit den Segen als W3C-Empfehlung zu geben ...

Du bist hier unnötig oder vielleicht unwissenderweiser zu harsch gegenüber der HTML 5 Bewegung bzw. gegenüber der von Dir empfundenen Tag Soup. Sämtliche Konzepte um die Syntax drehen sich nicht darum, einfach machen zu lassen, sondern vielmehr darum den bisher von jedem Browser selbst entwickelten Fehlerkorrekturalgorithmus zu standardisieren und zu vereinheitlichen. Das ist ebenso eine Standardisierung: Anstatt etwas komplett Neues zu erfinden, wird Bestehendes harmonisiert. Browsermacher profitieren dadurch, dass sie nicht das Rad neu erfinden müssen; Webautoren profitieren dadurch, dass die Lage harmonisiert wird; sie also in der Theorie Planungssicherheit haben.

Und der neue Parsing-Algorithmus ist eben nicht „Alles ist erlaubt“, wie der Begriff Tag Soup impliziert, er liefert im Gegensatz der drakonischen Fehlerbehandlung XMLs eine Fehlerbehandlung mit – die angesicht des jetztigen Webs nötig ist.

Tim

[Daniel Thoma]

Hallo Tim,

Du bist hier unnötig oder vielleicht unwissenderweiser zu harsch gegenüber der HTML 5 Bewegung bzw. gegenüber der von Dir empfundenen Tag Soup.

Ich habe mich zugegebenermaßen mit deren Ergebnisse nur sehr oberflächlich beschäftigt, aber mir missfällt die Entwicklung in die das ganze zu gehen scheint bzw. in die es nach der z.Z. vernehmbaren Kritik an XHTML und co. gehen soll. Ich meine hier auch noch nicht mal die WHATWG oder die neue HTML-Arbeitsgruppe. Gerade letztere hat ja gerade erst angefangen und es ist noch nicht wirklich klar, wohin sie wollen. Jedenfalls ist es für mich von außen nicht wirklich zu erkennen. Mir ging es um die Forderungen, die hier im Forum und sonst in der "Webstandarscommunity" zu vernehmen sind. Hier wird immer wieder so getan, als wäre der ganze XML-Weg von weltfremden Standardisierern eingeschlagen worden, als wäre XHTML im wesentlichen Tod und gäbe es im Prinzip auch keinen vernünftigen Grund, seine Implementierung in Browsern (besonderes im IE) zu fordern.

Sämtliche Konzepte um die Syntax drehen sich nicht darum, einfach machen zu lassen, sondern vielmehr darum den bisher von jedem Browser selbst entwickelten Fehlerkorrekturalgorithmus zu standardisieren und zu vereinheitlichen.

Wir haben mit XML eine Basis die Syntaktisch klar ist, die Erweiterungsmechanismen vorsieht, die mit XSchema eine Technologie hat, die Syntax von Sprachen relativ vollständig formal zu beschreiben und für die es zahllose, hervorragende Implementierungen gibt.
Was soll da ein Tag-Soup-Standard bringen? Will man die entsprechenden Konzepte dafür neu erfinden? Wie will man die Integration bestehender Standards wie SVG oder MathML ermöglichen, gar nicht?

Das ist ebenso eine Standardisierung: Anstatt etwas komplett Neues zu erfinden, wird Bestehendes harmonisiert.

Nun, das Ergebnis ist dann eben so gut wie das bestehende ist und bei scharfer Betrachtung wird man feststellen: Es ist nicht so besonders.
Gerade der HTML-Teil ist vom Konzept her alt und von seine Konzeptionierung an vielen Stellen für die heutigen Anforderungen besonders von Webanwendungen schlicht nicht mehr tragfähig. Formulare und XMLHtppRequest sind eine jämmerliche Krücke und überhaupt ist das Entwickeln von DHTML-Anwendungen ein softwaretechnischer Albtraum.
Es ist nicht damit getan, dass man eine Hand voll neuer JS-Objekte und Formularelemente einfügt. Wenn man Webanwendungen verbessern will, sind neue Konzepte erforderlich.

Browsermacher profitieren dadurch, dass sie nicht das Rad neu erfinden müssen

Ja, dass Browsermacher ihre Investitionen schützen können, scheint irgendwie der Hauptzweck der Übung zu sein. Natürlich geht es nicht ohne sie, aber es ist auch Aufgabe des W3C, sie etwas weiter zu treiben.

Webautoren profitieren dadurch, dass die Lage harmonisiert wird; sie also in der Theorie Planungssicherheit haben.

Ja und Theorie wird es wahrscheinlich bleiben. Wieso sollte der IE ein standardisiertes Tag-Soup können, wenn er noch nicht mal ein standardisiertes XML (in zusammenhang mit XHTML) kann? Und wenn doch, was soll es bringen, wenn es so konsequent implementiert wird wie CSS 2?
Abgesehen davon hatte ich beim Punkt HTML-Verarbeitung eigentlich schon ewig keine Probleme mehr.

Und der neue Parsing-Algorithmus ist eben nicht „Alles ist erlaubt“, wie der Begriff Tag Soup impliziert, er liefert im Gegensatz der drakonischen Fehlerbehandlung XMLs eine Fehlerbehandlung mit – die angesicht des jetztigen Webs nötig ist.

Automatische Fehlerkorrektur ist für das entstehen standardkonformer (und sichererer) Implementierungen und Dokumente ein Fluch. Ich glaube auch nicht, dass irgend ein Webautor mit einem halbwegs brauchbaren Editor nicht problemlos in der Lage wäre, wenigstens wohlgeformte Dokumente zu schreiben.
Natürlich kann man HTML 4 Unterstüzung nicht über Bord werfen, aber ich sehe keinen wirklichen Sinn darin, diesen Weg weiter zu gehen. Der einzige Grund dafür könnte die Hoffnung sein, dass MS für ein kontinuierliches weiterwursteln zu haben ist, während es eine konzeptionelle Weiterentwicklung oder auch nur den Wechsel zu XML ignorieren würde.

Über die WHATWG und die neue HTML-Arbeitsgruppe habe ich mir noch keine wirkliche Meinung gebildet. Ich beobachte das ganze etwas misstrauisch, aber ich hoffe, dass sie einen vernünftigen Weg finden wird, einerseits mit kleineren Schritten vorwärts zu kommen und andererseits nicht grundsätzlich vom bisherigen Weg des W3C abzuweichen. Ich sehe aber auf jeden Fall die Gefahr, dass jetzt durch die Standardisierung erreicht wird, dass HTML 4 ein paar weitere Font-Tags enthält, die es noch weitere 10-20 Jahre überleben lassen ohne dass es eine konzeptionelle Erneuerung erfährt.

Grüße

Daniel