XHTML ordnungsgemäß ausliefern

[Christoph]

Moin Daniel.

Mal ein paar Anmerkungen meinerseits. Ich selbst verwende derzeit noch HTML-Tidy zertifiziertes HTML 4.01 Strict.

Ich würde aber prinzipiell eher Gunnar zustimmen und als text/html ausgeliefertes XHTML 1.0 als gangbare Alternative sehen; wenn man möchte,kann man ja zusätzlich den Accept-Header auf application/xhtml+xml prüfen und gegebenenfalls den korrekten Mime-Type ausliefern.

Die Punkte, die du neu angesprochen hast, wirken auf Grund ihrer bloßen Anzahl erstmal erschreckend, in vielen Fällen braucht man sich darum aber wenig Gedanken zu machen:

* Die Zeichenkodierung: Es ist nur utf-8 bzw. utf-16 möglich, da sonst eine XML-Deklaration nötig wäre, was für IE6 schlecht ist. Du hast darauf mal geantwortet, dem sei nicht so, weil es ja den HTTP-Header gibt. Doch Schneegans ist hier auf meiner Seite!

Es ist im Hinblick auf XML-Software sinnvoll, auf den HTTP-Header verzichten zu können. Insbesondere kann ein XHTML-Dokument dann als Datei mit XML-Software bearbeitet werden. Bspw. MSXML ignoriert den HTTP-Header.

Warum nicht einfach UTF-8 verwenden? Problem gelöst ;)

* XML-Features dürfen nicht genutzt werden: Beispielsweise CDATA-Bereiche, Processing Instructions.

Die standen in HTML auch nicht zur Verfügung - mindert den Mehrwert, ist aber kein Problem per se.

* Sprachangaben müssen mit dem xml:lang- und dem lang-Attribut angegeben werden und darüberhinaus natürlich identisch sein.

Viele Seiten sind einsprachig - eine einzelne Angabe im Rootelement genügt in diesem Fall...

* Wie gesagt, Stylesheets und Skripte auslagern, denn nur weil bestimmte Zeichen in der Regel nicht vorkommen, bedeutet es nicht, dass sie das nicht tun.

Oder die CDATA-Anweisung auskommentieren...

* Leere Elemente müssen selbstschließend geschrieben werden und nicht mit der äquivalenten Schreibweise <element></element>

* nicht-leere Elemente ohne Inhalt dürfen nicht selbstschließend geschrieben werden, also kein <element/>

Relevant für automatische Generierung - wer HTML zu Fuß (bzw. per Hand) schreibt, dem sollte das keine Probleme bereiten.

* Außer für <, >, & und " dürfen keine benannten Entitäten verwendet werden sondern nur dezimale oder hexadezimale.

Deshalb verwendet man ja Unicode - dann braucht man für die Sonderzeichen keine Entities mehr!

* Vergleicht man die DTDs von HTML und XHTML so ergeben sich Differenzen: In der Strict Variante darf in HTML das form-Element ein name-Attribut besitzen, in XHTML nicht. In allen HTML-Varianten ist das ismap-Attribut für das input-Element erlaubt, aber in keiner XHTML-Variante.

Das ismap-Attribut habe ich noch nie verwendet, und ich bezweifle, dass ich da der einzige bin...

* Das Dokument darf nur in XML 1.0 erlaubte Zeichen enthalten. Z.B. kein U+000C, wie in HTML.

Nicht-grafische Zeichen interessieren mich nicht ;)

* Das von dir bereits genannte tbody-Element wird in HTML automatisch eingefügt, in XHTML ist es gänzlich optional.

Das birgt in der Tat Fehlerpotential.

* Stylesheets: Groß- und Kleinschreibung, besondere Eigenschaft des body-Elements.

In meinen Augen kein Problem.

* JavaScript/DOM: document.writeln darf nicht verwendet werden. Ebenso Level-1-Methoden des DOM wie createElement. Hier müssen die Namensraumfähigen Varianten dieser Methoden verwendet werden. Die kann der Internet Explorer allerdings nicht verarbeiten.

Ok. Spielt dieses Problem in der Praxis eine Rolle - will meinen: wie verhalten sich die gängigen Browser?

* Außerdem kann z.B. das isindex-Element in XHTML nicht verwendet werden.

Noch nie benutzt.

* Zudem habe ich schon meine Bedenken geäußert, wie ein XML-Parser mit XHTML umgehen kann. XHTML 1.0 und 1.1 befinden sich im selben Namensraum, den auch XHTML 2.0 (nach aktuellem Stand, nicht dem Working Draft Stand) ebenfalls diesen Namensraum verwenden. Alle drei sind aber zueinander inkompatibel. In 1.1 ist es nur das usemap-Attribut. In 2.0 sind es Formulare, Absätze, Überschriften, nahezu alles. Sag mir: Wie soll ein XML-parser hier zurechkommen? Doctype-Sniffing in XML? Damit verliert XML seinen Sinn.

Was aber mit dem Problem der Auslieferung von XHTML-Dokumenten an den Empfänger 'gängiger Browser' nichts zu tun hat.

Mein Fazit: Ob HTML oder XHTML ist in vielen Fällen Geschmacksfrage - d.h. mein Rat an Tom: Wähle den Weg des geringsten Widerstands, wirf eine Münze oder Folge dem Bauchgefühl.

Christoph

PS: Ich möchte noch auf eine weitere (zugegebenermaßen wenig praxistaugliche) Möglichkeit verweisen: der Auslieferunfg von XHTML als aplication/xml.