Hello out there!
Davon sprach ich gar nicht, sondern von der "magischen" Eigenschaft des body-Elements, Hintergrundfarbe, -bild und overflow auf das html-Element zu üebrtragen.
Achso, das meinst du. Was hindert einen Stylesheetautor daran, Angaben für den Viewport nicht für den Selektor 'body', sondern für 'html' zu machen? Das funktioniert in Tagsoup-Parsern als 'text/html' genauso wie bei XML-Verarbeitung als 'application/xhtml+xml' gleichermaßen. Kein Mehraufwand.
CDATA-Bereiche werden von Tagsoup-Parsern nicht verstanden.
?? Müssen doch gar nicht. Für Tagsoup-Parser sind Inhalte von 'script'- und 'style'-Elementen doch vom Typ CDATA, wie es HTML 4 spezifiziert ist.
(Ebendeshalb müssen ja (einige!) Scripte in XHTML als CDATA gekennzeichnet werden, damit sie als 'text/html' wie als 'application/xhtml+xml' gleichermaßen verarbeitet werden. Das betrifft eigentlich nur wenige, z.B. solche, in denen NCRs oder Entity-Referenzen vorkommen. [CDATA-PCDATA])
* Die Zeichenkodierung: Es ist nur utf-8 bzw. utf-16 möglich, […]
Was ist daran nachteilig? Es spricht eigentlich nichts dafür, eine andere Codierung als UTF-8 einzusetzen (bei Alphabeten, deren Buchstaben UTF-8-codiert 3 oder 4 Oktetts benötigen, evtl. UTF-16).
[…] 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!
Ich sage nur, dass „MUSS eine XML-Deklaration haben“ bei Vorhandensein externer Information falsch ist; nicht, dass es good practice wäre, bei anderer Codierung auf die XML-Deklaration zu verzichten.
Best practice jedoch: UTF-8, keine XML-Deklaration, keine Probleme.
* XML-Features dürfen nicht genutzt werden: Beispielsweise CDATA-Bereiche, […]
Wofür willst du die brauchen?
[…] Processing Instructions.
Das ist mir auch ein Dorn im Auge, Stylesheets nicht mit PIs einbinden zu können, sondern auf das 'link'-Element zurückgreifen zu müssen, dessen Semantik ich anders sehe.
* Sprachangaben müssen mit dem xml:lang- und dem lang-Attribut angegeben werden und darüberhinaus natürlich identisch sein.
In der Tat lästig.
Abhilfe könnte geschaffen werden, indem man im XHTML-Quelltext nur 'xml:lang' schreibt und diesen als 'application/xhtml+xml' an verständnisvolle Clients ausliefert; für andere Clients diese Quelle mit XSLT transformiert in HTML oder kompatibles XHTML ('text/html'). Die Transformation kann dann auch PIs in 'link'-Elemente umsetzen.
* Wie gesagt, Stylesheets und Skripte auslagern, denn nur weil bestimmte Zeichen in der Regel nicht vorkommen, bedeutet es nicht, dass sie das nicht tun.
?? Verstehe hier nicht ganz, worauf du hinauswillst.
* Leere Elemente müssen selbstschließend geschrieben werden und nicht mit der äquivalenten Schreibweise <element></element>
Das tut hier nichts zur Sache. Du sprachst von Mehraufwand des Schreibens von XHTML gegenüber dem Schreiben von HTML; dafür ist das kein Argument.
* nicht-leere Elemente ohne Inhalt dürfen nicht selbstschließend geschrieben werden, also kein <element/>
Das tut hier nichts zur Sache. Du sprachst von Mehraufwand des Schreibens von XHTML gegenüber dem Schreiben von HTML; dafür ist das kein Argument.
* Außer für <, >, & und " dürfen keine benannten Entitäten verwendet werden sondern nur dezimale oder hexadezimale.
Dieses Märchen hattest du schon in [</archiv/2007/11/t162468/#m1057290>] erzählt. Spätestens seit meiner Antwort [</archiv/2007/11/t162468/#m1060568>] sollte klar sein, dass dies falsch ist.
* 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.
Wofür sollte man das brauchen?
In allen HTML-Varianten ist das ismap-Attribut für das input-Element erlaubt, aber in keiner XHTML-Variante.
Wofür sollte man das brauchen?
* Das Dokument darf nur in XML 1.0 erlaubte Zeichen enthalten. Z.B. kein U+000C, wie in HTML.
Wozu willst du das Zeichen brauchen? Außerdem tut das hier nichts zur Sache. Du sprachst von Mehraufwand des Schreibens von XHTML gegenüber dem Schreiben von HTML; dafür ist das kein Argument.
* Das von dir bereits genannte tbody-Element wird in HTML automatisch eingefügt, in XHTML ist es gänzlich optional.
Damit ein XHTML-Dokument als Tagsoup denselben Elementbaum erzeugt wie bei Verarbeitung als XML muss also 'tbody' explizit vorhanden sein. Geringer Mehraufwand.
Aber nur nötig, wenn über JavaScript/DOM auf Tabellen zugegriffen wird oder im Stylesheet Selektoren stehen, die 'tbody' enthalten, was sich aber stets vermeiden lässt.
* JavaScript/DOM: document.writeln darf nicht verwendet werden.
Kein wirklicher Verlust.
Ebenso Level-1-Methoden des DOM wie createElement. Hier müssen die Namensraumfähigen Varianten dieser Methoden verwendet werden.
Nein, sie können nicht so ohne weiteres verwendet werden, wenn’s HTML-kompatibel sein soll.
Mit geringem Mehraufwand kann man einem Tagsoup-Parser – auch dem IE – aber diese Methoden beibringen:
if (!document.createElementNS)
{
document.createElementNS = function (namespace, element)
{
return document.createElement(element);
};
}
Wo steht eigentlich geschrieben, dass bei XML-Verarbeitung createElement() nicht verwendet werden darf?
* Außerdem kann z.B. das isindex-Element in XHTML nicht verwendet werden.
Noch so ’ne Kamelle! Auch dieses Märchen hattest du schon in [</archiv/2007/11/t162468/#m1057290>] erzählt. Spätestens seit meiner Antwort [</archiv/2007/11/t162468/#m1060568>] sollte klar sein, dass auch dies falsch ist.
* 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?
Namensräume haben damit gar nichts zu tun. Die beinhalten lediglich Elemente (Attribute). Ob und wie alle diese in einem Namensraum vorhandenen Elemente auch tatsächlich in einer diesen Namensraum verwendenden Sprache vorkommen dürfen, regelt die DTD (bzw. XML Schema). Bedenke, dass auch XHTML 1.0 Strict, XHTML 1.0 Transitional und XHTML 1.0 Frameset denselben Namenraum verwenden, aber unterschiedliche DTDs, also unterschiedliche Regeln haben.
See ya up the road,
Gunnar
--
„Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ (
Kirsten Evers)
Gunnar Bittersmann
molily
