Hallo Roland,
Da der JavaScript-Code implizit CDATA ist beziehungsweise als CDATA markiert werden kann, sollten Entities oder numerische Zeichenreferenzen abhelfen, sofern man den Code im Markup unterbringen will - oder sehe ich etwas falsch? Bei Kommentaren gilt dies natürlich nicht (die Zeichenreferenzen werden in dem Fall meines Wissens nicht interpretiert), aber beispielsweise der Operator && könnte ohne Kommentierung problematisch werden.
Kann es sein, dass ich selbst bezüglich des zitierten Texts am Kernproblem vorbeigeredet habe? Ich schlug Zeichenreferenzen zur Umgehung des Kommentarproblem mit -- vor (so sieht es zumindest aus ;)), wissentlich, dass Entities in Kommentaren nicht geparst werden...
Ein Client, der weiss, was <script> bedeutet (was noch nicht heisst, dass er es dann auch ausfuehren kann), wird keine Entities ersetzen, weil das in http://www.w3.org/TR/html40/types.html#h-6.2 eindeutig untersagt ist.
*grmbl* Ich hatte nur folgendes direkt unter http://www.w3.org/TR/html40/types.html#type-cdata gelesen (beziehungsweise hatte es noch im Kopf): »CDATA is a sequence of characters from the document character set and may include character entities. User agents should interpret attribute values as follows: * Replace character entities with characters, [...]« - Und folgende Ausnahme überlesen: »Although the STYLE and SCRIPT elements use CDATA for their data model, for these elements, CDATA must be handled differently by user agents. [->] Markup and entities must be treated as raw text and passed to the application as is. [<-]«.
Vielleicht habe ich es auch mit PCDATA (»parsed character data«, alleine vom Namen schon selbsterklärend) verwexelt, denn standardmäßig werden in XHTML (sofern es als XML ausgeliefert wird und der JavaScript-Code nicht als CDATA markiert wird) die Entities umgesetzt, siehe http://www.w3.org/TR/xhtml1/#h-4.8.
Im Falle der Ausfuehrung des Scripts wuerden Entities dann unveraendert an die Script-Engine uebergeben werden, was natuerlich fuer Fehler sorgt.
Genau das hat mein bisheriges Arbeiten mit JavaScript in HTML auch immer gezeigt...
Solche Clients wuerden die Auskommentierung ohnehin ignorieren (oder doch nicht? siehe [pref:t=38284&m=212247]), von daher koennte man das -- darin ruhig verwenden.
Das Browserverhalten scheint keinen durchsichtigen Regeln zu folgen, wahrscheinlich ist es ein stiller Konsens.
Das Problem mit -- besteht nur aus der Sicht solcher Clients, die <SCRIPT> nicht kennen. Fuer die ist dieses Tag etwa so sinnvoll wie <HOTZENKLOTZ>. Sie werden den Kommentar erkennen und - sofern sie halbwegs SGML-konform sind - Probleme mit dem -- haben.
.oO(Halbwegs SGML-komforme HTML-UAs, zudem noch Prä-HTML4 - so etwas gibt's? ;))
Daher besser -=1 verwenden, auch wenn's bloeder aussieht.
ACK.
Oder, wenn man sein HTML4-Dokument ordnungsgemaesz deklariert hat, sich darauf berufen, dass dieses Dokument eben HTML4 ist und solche Clients dieses eben nicht richtig verarbeiten koennen.
Folglich ein Dokument mit nicht auskommentiertem Scriptcode?
Aber jeder kann sich auf einen Tritt in den Arsch gefasst machen, wenn dieses Dokument dann nicht durch den Validator kommt! ;-)
Wie meinst du das, wenn ein HTML4-Client vorausgesetzt wird, ist das Kommentieren unnötig und folglich auch -- im Script erlaubt und unproblematisch...?
Oder man lagert sein Script halt in eine extra Datei aus. Immerhin war HTML mal als "abwaertskompatibel" gedacht.
Das ist sowieso die generell empfehlenswerte Methode, solange es nicht ausartet, denn immer wieder sehe ich äußerst kluge Autoren, welche verschiedene JavaScripts mit unterschiedlichen Aufgaben in mehreren Dateien unterbringen, sodass zusammen mit import-Anweisungen in den Styles oft bis zu fünf oder sechs zusätzliche HTTP-Anfragen pro Dokument gesendet werden.
Grüße,
Mathias