nicht angemeldet
Ich seh die Inkonsequenz nicht.
Da, wo das name-Attribut nur für Scripting erforderlich ist, ist es weggefallen. In den anderen Fällen nicht.
Jaja, welcher Sinn steckt dahinter? Die Aussage meines Postings war eben, dass ich die Unterscheidung zwischen »aus HTML-Sicht erforderlich« und »nur für Scripting erforderlich« bzw. »Bedeutung für HTML an sich« und »Bedeutung über HTML hinausgehend« nicht als Krtierium anerkenne, anhand dessen Elemente und Attribute einerseits zwecks Abwärtskompatibilität im Strict-Typ belassen werden und andere sang- und klanglos ausge-x-t werden, als wären sie irrelevant und nutzlos. Ich sehe beide Arten im Prinzip als gleich wichtig hinsichtlich der Kompatibilität an, und damit meine ich nicht die formale Kompatibilität und theoretische Funktionalität gemäß den Specs. Die Elemente und Attribute, die primär bzw. praktisch vollständig dem Scripting dienen, sind für mich genauso Bestandteil von HTML wie die anderen. Die Streichung dieser führt praktisch dazu, dass simpelste Scripte in XHTML nicht kompatibel mit HTML-Clients sein können, die über Prä-DOM unter Verwendung von HTML 4-Techniken durchaus bedienbar wären. Ob das W3C Scripting nun für vernachlässigbar hält, ändert nichts an der Tatsache, dass das Dokument als Gesamtgebilde nicht kompatibel zum HTML 4 Strict-Äquivalent mit ein paar name-Attributen mehr ist.
Wenn ich eine Sprache HTML-kompatibel nenne und davon rede, dass ein Dokument sowohl als HTML als auch als X(HT)ML verarbeitet werden kann, dann muss ich solche Umstände beachten. Ansonsten ist es teilweise kompatibel, teilweise nicht kompatibel. Beziehungsweise unter Umständen kompatibel. Dann deckt die Kompatibilität das Minimum ab, nämlich die Verarbeitung als HTML-Dokument an sich, alles drumherum wird ausgeklammert und für unwichtig befunden. Die Kompatibilität wird an die Voraussetzung gebunden, dass der Client das DOM beherrscht.
Natürlich findet sich in der Spec kein Wort dazu, der Leser wird nirgends darauf hingewiesen, das zeigt wohl die Unbekümmertheit. Aber es ist ja nicht einmal gesagt, dass XHTML im Prinzip nicht HTML-kompatibel sein kann und die sogenannte HTML-Kompatibilität nur auf unzureichenden HTML-Implementationen basiert.
Wobei sich die Notwendigkeit nicht nach real existierenden Browsern, sondern nach den HTML-Standards richtet.
Na wunderprächtig. Es ist waschechter Selbstbetrug, angesichts dessen von Kompatibilität zu sprechen (Phrasen wie »Although there is no requirement for XHTML 1.0 documents to be compatible with existing user agents, in practice this is easy to accomplish.«), und man verschließt die Augen vor den tatsächlichen Umständen.