nicht angemeldet
"-" in Kommentaren
Hallo Gemeinde,
Verbietet eine Regel, zehn "-" hintereinander in einen Kommentar zu schreiben?
Dies soll kein gültiges HTML sein:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title>Test</title>
</head>
<body>
<!-- ---------- -->
</body>
Der W3C Validator meint dazu:
Line 9, column 8: unterminated comment
</bo...
^
Line 8, column 16: comment started here
<!-- ---------- -->
^
Line 9, column 8: "BODY" not finished but document ended
</bo...
^
Gruß, Gunnar
-
Hallo,
Kommentare in HTML: <!-- //-->
gruß,
Severin-
Moin!
Kommentare in HTML: <!-- //-->
Was genau soll der Doppelslash // da?
Es richtig, mehrere (also ab zwei) aufeinanderfolgende - sind in Kommentaren verboten. Genaugenommen lautet die Regel anders, aber wenn man sich an diese vereinfachte haelt, ist man auf der sicheren Seite.
Man muss das uebrigens auch beim Auskommentieren von Script- oder Style-Bereichen beachten. Wenn man das denn schon tut, dann darf man darin auch kein -- verwenden. Das bedeutet fuer JavaScript, dass man dort den Dekrement-Operator -- nicht benutzen darf. Also Vorsicht! (In externen JS-Dateien, darf man das natuerlich wieder, schliesslich sind dort die HTML-Regeln bedeutungslos.)
So long
--
Bier trinken fetzt!!!-
Hallo,
mmmh mein "fehler", ich hab immer nur //--> benützt, und die andere art gar nicht gekannt.
zur bedeutung:
//--> beendet ein mehrzeiliges Kommentargruß,
Severin-
Hi,
mmmh mein "fehler", ich hab immer nur //--> benützt, und die andere art gar nicht gekannt.
zur bedeutung:
//--> beendet ein mehrzeiliges KommentarNein, // hat innerhalb eines SGML-Kommentares keinerlei Bedeutung.
Zur ursprünglichen Frage:
Innerhalb eines SGML-Konstruktes (das mit <! beginnt und mit > endet,
schaltet die Zeichenfolge -- zwischen nicht-Kommentar und Kommentar um.
<!-- ---------- -->
K N K N K N KK = Kommentar beginnt.
N = Nicht-Kommentar beginnt.Also ist vor dem > der Kommentar nicht beendet...
Am einfachsten: - innerhalb des Kommentars vermeiden.
Oder nur einzelne - oder Vierergruppen...
cu,
Andreas--
Der Optimist: Das Glas ist halbvoll. - Der Pessimist: Das Glas ist halbleer. - Der Ingenieur: Das Glas ist doppelt so groß wie nötig.-
Hallo,
Nein, // hat innerhalb eines SGML-Kommentares keinerlei Bedeutung.
mmmh kann es sein das sich das in lezter Zeit geändert hat?
ich hab meine Information fast wörtlich aus dem selfHTML Buch zitiert (Seite 73)gruß,
Severin-
Re!
Nein, // hat innerhalb eines SGML-Kommentares keinerlei Bedeutung.
mmmh kann es sein das sich das in lezter Zeit geändert hat?
ich hab meine Information fast wörtlich aus dem selfHTML Buch zitiert (Seite 73)AFAIK war das in Selfhtml 7 mit den // beschrieben, in der 8 aber nicht mehr. Das hat sich nicht geaendert, sondern war einfach noch nie so; das war also ein Fehler in Version 7.
// verwendet man nur dann, wenn man die Auskommentierung eines Script-Blocks abschliesst:
//--></SCRIPT>
Das versteckt das abschliessende --> vorm Scriptinterpreter. Und // verwendet man auch nur dann, wenn man eine Scriptsprache verwendet, die das als einzeiligen Kommentar erkennt (wie JS z.B.). Wuerde man VBScript verwenden, muesste man
'--></SCRIPT>
schreiben, bei PerlScript dagegen
#--></SCRIPT>
Ich glaube, das Schema ist klar.
Man beachte, dass am Ende eines CSS-Blocks das // keinen Sinn macht, denn CSS kennt diese Art der Kommentare nicht.
So long
--
Bier trinken fetzt!!!-
Hi,
Man beachte, dass am Ende eines CSS-Blocks das // keinen Sinn macht, denn CSS kennt diese Art der Kommentare nicht.
Nicht nur keinen Sinn hat ("macht" schon gleich gar nicht),
es ist schlichtweg falsch!cu,
Andreas--
Der Optimist: Das Glas ist halbvoll. - Der Pessimist: Das Glas ist halbleer. - Der Ingenieur: Das Glas ist doppelt so groß wie nötig.
-
-
-
-
-
Hallo Calocybe,
Man muss das uebrigens auch beim Auskommentieren von Script- oder Style-Bereichen beachten. Wenn man das denn schon tut, dann darf man darin auch kein -- verwenden. Das bedeutet fuer JavaScript, dass man dort den Dekrement-Operator -- nicht benutzen darf.
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.
Grüße,
Mathias-
Moin auch!
Man muss das uebrigens auch beim Auskommentieren von Script- oder Style-Bereichen beachten. Wenn man das denn schon tut, dann darf man darin auch kein -- verwenden. Das bedeutet fuer JavaScript, dass man dort den Dekrement-Operator -- nicht benutzen darf.
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.
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. Im Falle der Ausfuehrung des Scripts wuerden Entities dann unveraendert an die Script-Engine uebergeben werden, was natuerlich fuer Fehler sorgt. 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 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. Daher besser -=1 verwenden, auch wenn's bloeder aussieht. 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. Aber jeder kann sich auf einen Tritt in den Arsch gefasst machen, wenn dieses Dokument dann nicht durch den Validator kommt! ;-) Oder man lagert sein Script halt in eine extra Datei aus. Immerhin war HTML mal als "abwaertskompatibel" gedacht.
&& sollte keine Probs machen, da das ja in einem Kommentar steht.
So long
--
Bier trinken fetzt!!!-
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-
Re!
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?
Genau.
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...?
Genau. Aber wehe das ist dann nicht wirklich HTML4... ;-)
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.
Wenn man bedenkt, dass manche Seiten dutzende kleine Layoutgrafiken verwenden (weil es ohne runde Tabellenecken eben nicht geht), dann machen fuenf JavaScripts mehr oder weniger auch keinen grossen Unterschied mehr.
Aber, die vielen Verbindungsaufbauten (Mehrzahl von Aufbau?) sollen ja mit Keep-Alive in HTTP/1.1 unschaedlich gemacht werden. Weiss nicht, wie weit da die Browserunterstuetzung ist -- Mozilla kann es offenbar.
So long
--
Bier trinken fetzt!!!
-
-
-
-
-