Hallo,
Der Versuch, Inline-Skriptcode vor XML (mittels CDATA-Insel) so zu verstecken, dass sich auch HTML-kompatible Parser nicht dran stören, ist nur noch als "abenteuerlich" zu bezeichnen.
Irgendwie scheinst du da etwas fundamental missverstanden zu haben, ansonsten kann mir ich deinen Einwand nicht erklären...
Warum wurde eingebetteter Script- und Style-Code überhaupt auskommentiert? - Für Scripte: Weil Netscape 1 und IE 2 kein JavaScript können und den Code einfach ausgeben würden.
(Die Versionen hatte ich mal für http://de.selfhtml.org/javascript/intro.htm#javascriptbereiche recherchiert. Für style hatte ich das auch mal mal vor Jahren herausgesucht, dürfte irgendwo im Archiv liegen.)
Conclusio: Für Browser darüber können wir auf Auskommentierung verzichten.
Was machen wir nun, wenn in einem HTML-4-Dokument HTML-Code in <script>...</script> auftaucht? - Wir schreiben ihn ganz normal hin, verändern aber End-Tags von </ zu </. Sache gegessen.
Einfach weil - genau wie in HTML auch - die XHTML-Struktur CDATA mit Javascript-Kommentierung vor der Interpretation als Code geschützt werden muß
In HTML muss man den Inhalt von script nicht vor der Interpretation schützen. Kann man eigentlich gar nicht. Denn die Browser ignorieren ihn ohnehin. Auch, wenn man vergessen hat, </ mit </ zu maskieren. Die Browser sind so fehlertolerant, dass sie alles von <script> zu </script> als Script behandeln. (Gut, »</script>« muss man natürlich immer als »</script>« maskieren.)
In XHTML gibts qua XML solche Sonder-Parsing-Regeln nicht, deshalb muss man den Code ggf. mit CDATA-Bereichen umschließen, da hast du Recht.
Das Beispiel von Hixie ist einfach absurd und aus der Luft gegriffen. Das ist ohnehin ein bloßes Denkexperiment: Es geht dabei darum, XHTML an Netscape 1 auszuliefern. Ja, sehr witzig... Das habe ich zumindest nicht vor. Und wenn, dann lagere ich Scripte aus. Was ohnehin empfohlen ist...
Das Denkexperiment sollte zeigen, dass die HTML-Kompatiblität von XHTML in der Praxis nicht wirklich gegeben ist. Das mag auf der theoretischen (absurde SGML-Deklaration von HTML) sowie der praktischen Ebene (Stand 1994) auch korrekt sein, spielt heute aber keine Rolle mehr.
Mathias