XHTML ordnungsgemäß ausliefern

[Daniel unreg]

Hallo,

Ich bin mir nicht sicher, ob man das den Autoren zum Vorwurf machen kann. Eine Spezifikation ist kein Tutorial. Die Autoren waren so freundlich, in einem informellen Anhang einige Aspekte anzusprechen. Es kann nicht Aufgabe der XHTML-Spec sein, im Detail auf JavaScript einzugehen.

Das ist ganz klar, hier widerspreche ich dir nicht. Damit zeige ich nur, dass Anhang-C-kompatibles XHTML einen nicht weiterbringt.

Verwende bei jeder Tabelle, die du später übers DOM ansprechen willst, 'tbody'. Der Mehraufwand hält sich in engen Grenzen.

Und wie willst du im DOM ein Element oder Attribut hinzufügen?

Schreibe in Stylesheets die Elementtypen in Selektoren klein. Kein Mehraufwand.

Davon sprach ich gar nicht, sondern von der "magischen" Eigenschaft des body-Elements, Hintergrundfarbe, -bild und overflow auf das html-Element zu üebrtragen.

Setze JavaScript-Bereiche (sofern überhaupt JavaScript im HTML-Dokument steht), die als CDATA und PCDATA unterschiedlich interpretiert werden würden, als CDATA-Bereiche. Um die Überlegung zu ersparen, welche das betrifft, tu es bei allen. Der Mehraufwand hält sich in engen Grenzen.

CDATA-Bereiche werden von Tagsoup-Parsern nicht verstanden.
Zeichen wie <, & und ]]> mögen zwar in der Regel nicht vorkommen, sie tun es aber dennoch. Deswegen sehe ich es als Pflicht (und das tue ich auch bei HTML), Stylesheets und Skripte auszulagern.

Ich weiß nicht, wo du da "großen Mehraufwand" siehst.

Nun, du beachtest auch nicht alle wichtigen Punkte, es fehlen z.B.

* 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.

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

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

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

* 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/>

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

* 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 Dokument darf nur in XML 1.0 erlaubte Zeichen enthalten. Z.B. kein U+000C, wie in HTML.

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

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

* 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.

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

* 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.

Das sind alle Punkte, die mir bis jetzt eingefallen sind.

Gruß;