XHTML 1.0 oder einen Schritt zurück?

[Alex]

Im Moment bin ich hin- und hergerissen bei der Entscheidung, ob ich zukünftig wieder mit HTML 4.01 oder weiter mit XHTML 1.0 arbeiten soll.

Ein sehr schweeres Thema, wie ich festgestellt habe, denn meine Entscheidung hängt zur Zeit von der Problematik Kodierung und MIME-Typ ab.

Ich bin in der Lage, Dokumente strukturiert zu verfassen und dann mit hilfe einiger <div> und Stylesheets ein Design zu gestalten. Beides ist also getrennt. Der W3C Validator, Validome und sogar der Schema Validator von Schneegans geben mir grünes Licht. Also lassen wir diesen Aspekt der Dikussion außen vor.

Probleme macht hier natürlich der IE (7 wird auch kein XHTML "können"? ; ;). Obwohl die Kodierung in UTF-8 kein Problem darstellen sollte, verwirrt mich das ganze gerede um den MIME Typ viel mehr. Christoph Schneegans' Empfehlung lautet text/html zu verwenden, aber nahezu jede andere Quelle rät davon ab, da dieser Typ anstatt application/xhtml+xml zu allerlei Problemen führt, die ich allerdings auf gut Deutsch nicht kapiere.

Bisher hatte ich XHTML Dokumente in ISO 8859-1 und mit application/xhtml+xml auf meinem Server liegen. Die XML-Deklaration habe ich auf unsaubere Weise für IE-Nutzer entfernt. Die Dokumente konnten angezeigt werden, aber ich bin mir nun nicht sicher, ob es an den Dateiendungen (.html oder .php) lag oder der üblichen verkorkstheit des IE, immerhin zeigte auch der mir schon XML-Fehler an.

Ich fürchte ich hab es immer noch nicht geschafft eine konkrete Frage zu stellen, darum: wäre es für mich sinnvoller, - da ich den ganzen Brei um Kodierung und MIME Typ nicht ganz verstehe - anstatt XHTML zu verwenden, wieder auf HTML umzusteigen?

Wenn ja, muss ich dann tatsächlich damit rechnen, dass der W3C Validator mir allerlei (unbeabsichtigter) Fehler durchgehen lässt?

[Vinzenz Mai]

Hallo Alex,

Probleme macht hier natürlich der IE (7 wird auch kein XHTML "können"? ; ;).

das verstehe ich nicht. Bereits der IE 6 hat mit XHTML prinzipiell gesehen kein Problem. Wo ist Dein Problem?

Vielleicht hilft Dir das SELFHTML-Kapitel Unterschiede zwischen XHTML und HTML weiter. Es enthält viele nützliche Praxistipps.

Freundliche Grüße

Vinzenz

[Der Martin]

Hallo Vinzenz,

Bereits der IE 6 hat mit XHTML prinzipiell gesehen kein Problem.

wenn es als text/html ausgeliefert wird, nicht. Wenn es aber, wie ursprünglich vorgesehen, als application/html+xml ausgeliefert wird, hat er sehr wohl ein Problem damit: Er zeigt das Dokument nicht an, sondern bietet es zum Speichern an. Ganz abgesehen von der immer wieder diskutierten Problematik mit dem XML-Prolog, der beim IE den Quirks-Mode provoziert.
Also muss man schon in zwei Punkten von der "reinen Lehre" abweichen, damit man diesen Browser trotzdem zufriedenstellend bedienen kann.

Ciao,
 Martin

[Alex]

Hallo Vinzenz und Martin,

Bereits der IE 6 hat mit XHTML prinzipiell gesehen kein Problem.

wenn es als text/html ausgeliefert wird, nicht. Wenn es aber, wie ursprünglich vorgesehen, als application/html+xml ausgeliefert wird, hat er sehr wohl ein Problem damit: Er zeigt das Dokument nicht an, sondern bietet es zum Speichern an. Ganz abgesehen von der immer wieder diskutierten Problematik mit dem XML-Prolog, der beim IE den Quirks-Mode provoziert.
Also muss man schon in zwei Punkten von der "reinen Lehre" abweichen, damit man diesen Browser trotzdem zufriedenstellend bedienen kann.

Das wollte ich damit ansprechen, die Formulierung war ungeschicht, das möge man mir verzeihen.

Hier liegt nun auch mein Problem. Der IE kommt mit application/xhtml+xml nicht klar, und das ganze zwar in der Deklaration und im (bzw. für IE nur) meta anzugeben obwohl von HTTP aus text/html gesendet wird erscheint mir hier auch gegen die genannte "reine Lehre".

An sich hätte ich kein Problem alles auf text/html umzuschreiben, allerdings blicke ich durch die damit Entstehende Problematik, nicht ganz durch, bzw. das was als solche gepredigt wird.

Gruss, Alex

[molily]

Hallo,

Hier liegt nun auch mein Problem. Der IE kommt mit application/xhtml+xml nicht klar, und das ganze zwar in der Deklaration und im (bzw. für IE nur) meta anzugeben obwohl von HTTP aus text/html gesendet wird erscheint mir hier auch gegen die genannte "reine Lehre".

Das meta-Element mit http-equiv="Content-Type" erfüllt nur einen Zweck: Die Kodierungsangabe für den Fall zu beinhalten, dass das XHTML-Dokument als HTML verarbeitet wird.

Insofern wäre

<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" />

ziemlich sinnlos - das juckt keinen Browser, der arbeitet schon im HTML-Modus in dem Fall, dass er diesem Element Aufmerksamkeit schenkt.

Wenn das Dokument als XHTML verarbeitet wird, dann wird diese meta-Angabe sowieso ignoriert, denn dann gelten die XML-Regeln zur Bestimmung der Kodierung eines Elements. Kurz gesagt heißt das in der Praxis: Wenn die Kodierung nicht UTF-8 ist, muss eine XML-Deklaration mit Kodierungsangabe vorhanden sein.

Die Verarbeitbarkeit eines Dokuments als HTML *und* als XHTML bringt man unter ein Hut, indem man UTF-8 benutzt, die XML-Deklaration weglässt und eine herkömmliche meta-Kodierungsangabe setzt.

An sich hätte ich kein Problem alles auf text/html umzuschreiben, allerdings blicke ich durch die damit Entstehende Problematik, nicht ganz durch, bzw. das was als solche gepredigt wird.

Wie gesagt, text/html musst du sowieso verwenden und im meta-Element natürlich auch angeben. XHTML wurde extra dafür ausgelegt, auch mit alten Browsern kompatibel zu sein.

Die üblichen Einsprüche gegen HTML-kompatibles XHTML (http://hixie.ch/advocacy/xhtml usw.) gehen lediglich darauf hinaus, dass niemand, der nur HTML-kompatibles XHTML schreibt, wirklich XHTML/XML versteht und praktisch anwenden kann.

Mathias

[Alex]

Hallo Mathias

ich bedanke mich vielmals für die zahlreichen Erläuterungen, ich komme mit der ganzen Problematik nun besser zurecht.
Ich werde zwar noch eine Nacht drüber schlafen, aber ich kann schon jetzt sagen, dass mir die Heilfe im Forum sehr in meinem Entscheidungsprozess geholfen hat.

Danke, Alex

[Vinzenz Mai]

Hallo

Bereits der IE 6 hat mit XHTML prinzipiell gesehen kein Problem.

wenn es als text/html ausgeliefert wird, nicht. Wenn es aber, wie ursprünglich vorgesehen, als application/html+xml ausgeliefert wird,

was für XHTML eben überhaupt nicht erforderlich ist. Und darum geht es mir.

hat er sehr wohl ein Problem damit: Er zeigt das Dokument nicht an, sondern bietet es zum Speichern an. Ganz abgesehen von der immer wieder diskutierten Problematik mit dem XML-Prolog, der beim IE den Quirks-Mode provoziert.
Also muss man schon in zwei Punkten von der "reinen Lehre" abweichen, damit man diesen Browser trotzdem zufriedenstellend bedienen kann.

Und? Was hat die "reine Lehre" mit XHTML zu tun? Nichts. Das von mir verlinkte Kapitel gibt übrigens gerade zum MIME-Type einen wundervollen Praxistipp.

Freundliche Grüße

Vinzenz

[Ashura]

Hallo Alex.

Ich fürchte ich hab es immer noch nicht geschafft eine konkrete Frage zu stellen, darum: wäre es für mich sinnvoller, - da ich den ganzen Brei um Kodierung und MIME Typ nicht ganz verstehe - anstatt XHTML zu verwenden, wieder auf HTML umzusteigen?

Auch einfaches HTML wird mit einem MIME-Typen (text/html) ausgeliefert.

Und um die Kodierungsproblematik kommst du auch bei „normalem“ HTML nicht herum. Dabei ist es gar nicht so schwer: du musst nur konsequent überall ein und die selbe Kodierung angeben. Also sowohl beim Speichern der (X)HTML-Dokumente selbst, als auch in der <http://de.selfhtml.org/html/xhtml/unterschiede.htm#xml_deklaration@title=optionalen XML-Deklaration> und dem HTTP-Äquivalent zum Content-Type-Header in Form des passenden http://de.selfhtml.org/html/kopfdaten/meta.htm#zeichenkodierung@title=meta-Elements in als auch beim Content-Type-Header selbst, wenn die Dokumente per HTTP aufgerufen werden.

Wenn du in allen genannten Feldern immer explizit ISO-8859-1 oder UTF-8 nutzt, kann es eigentlich zu keinen Missverständnissen kommen, wenn der Client nicht völlig kaputt ist.

Um dir viel Arbeit zu ersparen, empfehle ich dir UTF-8 zu nutzen.

Einen schönen Donnerstag noch.

Gruß, Ashura

[Alex]

Hallo Ashura

Auch einfaches HTML wird mit einem MIME-Typen (text/html) ausgeliefert.

Ja, soweit ist es mir klar, nur bei einfachem HTML besteht keine Problematik welchem MIME-Typen ich nun verwenden soll, es gibt ja nur text/html.

Wenn du in allen genannten Feldern immer explizit ISO-8859-1 oder UTF-8 nutzt, kann es eigentlich zu keinen Missverständnissen kommen, wenn der Client nicht völlig kaputt ist.

Um dir viel Arbeit zu ersparen, empfehle ich dir UTF-8 zu nutzen.

Wie gesagt, die Kodierung ist das kleinere Übel, aber ich werde mir deinen Rat zu Herzen nehmen.

Danke, Alex

[molily]

Hallo,

Christoph Schneegans' Empfehlung lautet text/html zu verwenden, aber nahezu jede andere Quelle rät davon ab, da dieser Typ anstatt application/xhtml+xml zu allerlei Problemen führt, die ich allerdings auf gut Deutsch nicht kapiere.

Realistisch ist heutzutage nur sogenanntes HTML-kompatibles, also abwärtskompatibles XHTML mit dem MIME-Typ text/html. (Entsprechend fähigen Browsern kann man natürlich fallweise application/xhtml+xml vorsetzen.)

Natürlich führt diese Vorgehensweise zu einigen Problemen - weil die wenigsten Leute die Eigenheiten von XHTML beachten, wenn ihre XHTML-Dokumente nie so verarbeitet werden, wie es für XHTML vorgesehen ist.

Das Problem dabei ist: XHTML verliert unter Umständen die meisten seiner Vorteile, wenn XHTML lediglich als text/html ausgeliefert wird.

Das ist aber eher ein theoretisches Argument. Wenn du dein XHTML sowieso mit Christoph Schneegans’ Schema-Validator oder Validome überprüfst, ist das XHTML auch als XHTML brauchbar, nicht nur als »HTML-ähnliches Markup«.

Bisher hatte ich XHTML Dokumente in ISO 8859-1 und mit application/xhtml+xml auf meinem Server liegen.

Das kann nicht sein - IE würde nichts daraus machen.

Der MIME-Type ist übrigens nicht das, was du in der meta-Angabe angibst, der MIME-Typ wird vom Webserver in einem HTTP-Header namens Content-Type übertragen (siehe View HTTP Request and Response Header).

Die Dokumente konnten angezeigt werden, aber ich bin mir nun nicht sicher, ob es an den Dateiendungen (.html oder .php) lag

Höchstwahrscheinlich - .html und .php liefert der Webserver standardmäßig als text/html aus.

oder der üblichen verkorkstheit des IE, immerhin zeigte auch der mir schon XML-Fehler an.

Das macht er nur bei text/xml bzw. application/xml. In dem Fall versteht er aber nicht, dass dieses Markup HTML ist, er setzt es also nicht entsprechend um.

Ich fürchte ich hab es immer noch nicht geschafft eine konkrete Frage zu stellen, darum: wäre es für mich sinnvoller, - da ich den ganzen Brei um Kodierung und MIME Typ nicht ganz verstehe - anstatt XHTML zu verwenden, wieder auf HTML umzusteigen?

Solange du die XHTML-Dokumente nicht irgendwo als XML verarbeitest bzw. verarbeiten lässt, brauchst du dir über diese Problematiken keine Gedanken machen.

Allerdings: Solange du die XHTML-Dokumente sowieso nicht als XML verarbeitest, kannst du natürlich auch gleichermaßen HTML 4.01 verwenden. Anders herum: Wenn es dir wichtig ist, dass du die Vorteile von XHTML nutzen kannst, dann musst du dich über diese Themen informieren.

(...) wieder auf HTML umzusteigen?
Wenn ja, muss ich dann tatsächlich damit rechnen, dass der W3C Validator mir allerlei (unbeabsichtigter) Fehler durchgehen lässt?

In HTML 4 sind einige syntaktische Perversitäten möglich und gültig, die man eigentlich nicht verwenden will, denn die Browser sehen sie als Fehler an.

Mathias

[Auge]

Hallo

Solange du die XHTML-Dokumente nicht irgendwo als XML verarbeitest bzw. verarbeiten lässt, brauchst du dir über diese Problematiken keine Gedanken machen.

full ACK

In HTML 4 sind einige syntaktische Perversitäten möglich und gültig, die man eigentlich nicht verwenden will, denn die Browser sehen sie als Fehler an.

Man muss sie ja nicht verwenden, die Perversitäten. :-)

Ich halte den Hype um XHTML sowieso für groben Unfug. Alle wollen mitmachen, es muss auch gleich "strict" sein, damit man sich bauchmiezeln (lassen) kann, und dann kommen sie alle an und wundern sich, warum z.B. die Verwendung von 'target' vom Validator als Fehler erkannt wird.

Solange der von dir oben genannte Fall der Weiterverarbeitung als XML nicht gegeben ist, und das ist er meist nicht, kann man es auch bei HTML belassen. Und wer 'target' benutzen will, der muss halt "in transitional" schreiben. punktum.

Tschö, Auge

[Alex]

Hallo Auge

full ACK

Die Abkürzung ist mir nicht bekannt :(

Man muss sie ja nicht verwenden, die Perversitäten. :-)

Das nicht, aber allzuschnell schleichen sie sich ganz von selbst ein.

Ich halte den Hype um XHTML sowieso für groben Unfug. Alle wollen mitmachen, es muss auch gleich "strict" sein, damit man sich bauchmiezeln (lassen) kann, und dann kommen sie alle an und wundern sich, warum z.B. die Verwendung von 'target' vom Validator als Fehler erkannt wird.

Auch so etwas gibt es. Ich allerdings  sehe es wirklich als eine Wohltat, die die Strict-Variante hier mit sich bringt.

Solange der von dir oben genannte Fall der Weiterverarbeitung als XML nicht gegeben ist, und das ist er meist nicht, kann man es auch bei HTML belassen. Und wer 'target' benutzen will, der muss halt "in transitional" schreiben. punktum.

Ich habe jetzt mal versucht ein HTML Grundgerüst zu schreiben und konnte kaum widerstehen die XHTML spezifischen Eigenheiten gleich miteinzubauen. Sofern es keine dramatischen Folgen hat werde ich also  dabei bleiben.

Danke, Alex

[Auge]

Hallo

full ACK

Die Abkürzung ist mir nicht bekannt :(

ACK steht für acknowledge (anerkennen, hier: bestätigen), also: 'volle Zustimmung'.

Man muss sie ja nicht verwenden, die Perversitäten. :-)

Das nicht, aber allzuschnell schleichen sie sich ganz von selbst ein.

Halt' ich für Blödsinn. Gesetzt den Fall, du schreibst (X)HTML selbst, also händisch, schleichen sich solche Dinge ein oder auch nicht, unabhängig davon, ob du HTML oder XHTML schreibst. Was irgendwelche WYSIWYG-Programme machen, sei dahingestellt.

Ich halte den Hype um XHTML sowieso für groben Unfug. Alle wollen mitmachen, es muss auch gleich "strict" sein, damit man sich bauchmiezeln (lassen) kann, und dann kommen sie alle an und wundern sich, warum z.B. die Verwendung von 'target' vom Validator als Fehler erkannt wird.

Auch so etwas gibt es. Ich allerdings  sehe es wirklich als eine Wohltat, die die Strict-Variante hier mit sich bringt.

Ich benutze, wohl aus Gewohnheit, HTML 4.01. Auch in diesem Dialekt zwingt mich niemand, Attribute zu benutzen, die in 'strict' verboten sind. Mir ging es ja eher darum, dass es 'in' ist, XHTML (strict) zu schreiben, ohne sich deshalb der Konsequenzen bewusst zu sein (neben 'target' z.B. auch der MSIE, siehe einen Thread weiter oben).

Solange der von dir oben genannte Fall der Weiterverarbeitung als XML nicht gegeben ist, und das ist er meist nicht, kann man es auch bei HTML belassen. Und wer 'target' benutzen will, der muss halt "in transitional" schreiben. punktum.

Ich habe jetzt mal versucht ein HTML Grundgerüst zu schreiben und konnte kaum widerstehen die XHTML spezifischen Eigenheiten gleich miteinzubauen.

hehe

Sofern es keine dramatischen Folgen hat werde ich also  dabei bleiben.

Tue dies. :-)
Ich habe ja nicht umsonst "kann man es auch bei HTML belassen" geschrieben (man achte auf: kann).

Tschö, Auge

[molily]

Hallo,

Man muss sie ja nicht verwenden, die Perversitäten. :-)

Natürlich will man das nicht. Der Punkt ist, dass es unabsichtlich passieren kann - und jeder SGML-Parser wird es als korrekt durchgehen lassen (z.B. SHORTTAG).

Ich halte den Hype um XHTML sowieso für groben Unfug. Alle wollen mitmachen, es muss auch gleich "strict" sein, damit man sich bauchmiezeln (lassen) kann, und dann kommen sie alle an und wundern sich, warum z.B. die Verwendung von 'target' vom Validator als Fehler erkannt wird.

Ich weiß, dass das eher eine Polemik sein soll, aber bitte bringe die Fragen HTML vs. XHTML nicht mit der Frage Strict vs. Transitional in Verbindung. Sie haben inhaltlich nämlich nichts miteinander zu tun.

Mathias

[Alex]

Hallo Mathias

Das kann nicht sein - IE würde nichts daraus machen.

Ja, hier hätte ich mich genauer ausdrücken müssen. Gemeint war auch hier die Angabe im meta-tag. Dann hat der IE wahrscheinlich keine Probleme gemacht, da der Webserver selbst noch text/html gesendet hat.

Solange du die XHTML-Dokumente nicht irgendwo als XML verarbeitest bzw. verarbeiten lässt, brauchst du dir über diese Problematiken keine Gedanken machen.

Allerdings: Solange du die XHTML-Dokumente sowieso nicht als XML verarbeitest, kannst du natürlich auch gleichermaßen HTML 4.01 verwenden. Anders herum: Wenn es dir wichtig ist, dass du die Vorteile von XHTML nutzen kannst, dann musst du dich über diese Themen informieren.

(...) wieder auf HTML umzusteigen?
Wenn ja, muss ich dann tatsächlich damit rechnen, dass der W3C Validator mir allerlei (unbeabsichtigter) Fehler durchgehen lässt?

In HTML 4 sind einige syntaktische Perversitäten möglich und gültig, die man eigentlich nicht verwenden will, denn die Browser sehen sie als Fehler an.

Wenn ich das als Vorteil von XHTML durchgehen lasse, ist es schon ein starkes Argument, jedoch habe ich nur sehr wenig Praxiserfahrung mit dem W3C Validator und HTML um sagen zu können, dass mir das nicht passt. Insofern bleibe ich vermutlich beim alten neuen.

Danke, Alex