Kommentar in XHTML

[jo]

hallo,

Wenn man einen HTML kommentar XHTML like schreiben, muß man diesen auch mit / schließen

[code lang=html]
<!--
XHTML kommentar ?
-- />
oder
<!--
XHTML kommentar ?
-->
[/html]

gruß

jo

[Tim Tepaße]

Hallo,

Wenn man einen HTML kommentar XHTML like schreiben, muß man diesen auch mit / schließen

Nein. Im Prinzip werden Kommentare mit dem "--" geöffnet und mit einem weiteren "--" geschlossen, im Prinzip sollte man also nicht mit aufeinander folgenden Strichen in Kommentaren rumkaspern. Allerdings verhalten die Browser sich da unterschiedlich, dank einer Kampagne, die ein Unruhestifter teilweise zurecht in den letzten Jahren geführt hat.

Du hättest dies auch rausfinden können, indem Du die Schreibweise von Kommentaren in XML in SELFHTML nachgeschlagen hättest, XHTML 1.0 ist ja nichts anderes als HTML in XML-Syntax.

Tim

[Ingo Turski]

Hi,

Wenn man einen HTML kommentar XHTML like schreiben, muß man diesen auch mit / schließen

ganz so dumm finde ich die Frage nicht, denn Kommentare sowie auch der DOCTYPE und xml-Deklaration bilden eine Ausnahme vom Prinzip der stets zu schließenden Tags.

freundliche Grüße
Ingo

[Tim Tepaße]

Hallo Ingo,

ganz so dumm finde ich die Frage nicht, denn Kommentare sowie auch der DOCTYPE und xml-Deklaration bilden eine Ausnahme vom Prinzip der stets zu schließenden Tags.

Jain. Ganz spitzfing im XML- bzw. im SGML-Sinne handelt es sich bei diesen Konstrukten nicht um Tags.

In XML beginnt die Produktionsregel für (Start-) Tags mit "'<' Name". Name bezeichnet dann die Produktionsregeln für Namen; diese beginnt mit "(Letter | "_" | ":"), wobei Letter dann eine Gruppe von Zeichen ist, die nur aus Buchstaben besteht. Indirekt sagt das dann, dass das X bei der Zeichenkette "<X" z.B. kein "!" oder "?" sein darf, wenn es sich um einen Tag handelt. Genauer steht es im SGML Standard, dort ist die Zeichenkette "<" als „Start-tag open (STAGO)“ definiert, dagegen sind die Zeichenketten "<!" und "<?" als „Markup declaration open (MDO)“ bzw. „Processing instruction open (PIO)“ definiert. XML hat dieses Verhalten also von XML geerbt.

Dass es etwas .. komisch ist, zu sagen "<X..." impliziert einen Tag, aber nur, wenn X weder ein "!" noch ein "?" ist, liegt natürlich auf der Hand. Meine Vermutung geht dahin, dass die Autoren des SGML Standards die direkte Eindeutigkeit der einfacheren Begreifbarkeit geopfert haben. Nur ein (bzw. zwei verwandte) Trennzeichen für Informationen zu haben strukturiert das Dokument auf den ersten Blick besser, auch wenn es dann zu dem Missverständnis „Alles sind Tags“ kommen kann.

Tim

[Thomas J.S.]

Hallo Tim,

Meine Vermutung geht dahin, dass die Autoren des SGML Standards die direkte Eindeutigkeit der einfacheren Begreifbarkeit geopfert haben.

Der Ansicht bin ich nicht.
Mehrere verschiedene Delimiters, hätten einen größeren Aufwand bedeutet und zudem ist die Rolle eines Delimiters enderbar.
So wird im Anex L der SGML-Spez (Added Requirements for XML) in der "SGML Declaration for XML" folgendes "umdefiniert":

DELIM
GENERAL SGMLREF
HCRO "&#38;#x" -- Ampersand followed by "#x" (without quotes) --
   Das ist: "Hex Character Reference Open" (delimiter)
   Ist nicht in der "General Reference Delimiter Set" definiert.
    (CRO ist mit "&#" definert)

NESTC "/"
  Das ist: NET-enabling start-tag close
  Ist nicht in der "General Reference Delimiter Set" definiert.

NET ">"
  Das ist: Null End Tag
  Referenz aus SGML wäre: "/"

PIC "?>"
 Das ist: Processing instruction close
 Referenz aus SGML wäre: ">"

Grüße
Thomas

[Tim Tepaße]

Hallo Thomas,

Mehrere verschiedene Delimiters, hätten einen größeren Aufwand bedeutet und zudem ist die Rolle eines Delimiters enderbar.

Du hast mich missverstanden, ich habe mich offenbar falsch ausgedrückt. Mir ging es weniger um die Einfachkeit der technischen Implementation¹ als um die Begreifbarkeit für menschliche Leser. Ich kann mir nämlich nicht vorstellen, dass die Autoren sich darüber keine Gedanken gemacht haben. Und ein Begrenzungszeichen ist nun mal einfacher zu merken als je nach Inhalt verschiedene; in normaler Sprache setzen begrenzen wir Worte auch mit Leerzeichen und nicht nach Wortart mit anderen Zeichen, wie z.B.{Nomen}mit geschweiften{Klammern}. ;)

Tim

[Thomas J.S.]

Hallo Tim,

Mehrere verschiedene Delimiters, hätten einen größeren Aufwand bedeutet und zudem ist die Rolle eines Delimiters enderbar.

Du hast mich missverstanden, ich habe mich offenbar falsch ausgedrückt. Mir ging es weniger um die Einfachkeit der technischen Implementation¹

Und wo ist die Fußnote zu 1? ;-)

als um die Begreifbarkeit für menschliche Leser. Ich kann mir nämlich nicht vorstellen, dass die Autoren sich darüber keine Gedanken gemacht haben. Und ein Begrenzungszeichen ist nun mal einfacher zu merken als je nach Inhalt verschiedene; in normaler Sprache setzen begrenzen wir Worte auch mit Leerzeichen und nicht nach Wortart mit anderen Zeichen, wie z.B.{Nomen}mit geschweiften{Klammern}. ;)

Wenn wir die Sprache als Analogie nehmen, was (gar nicht so) schlecht ist, müssen wir das genau tun. Ein Punkt in einem Satz markiert normalerweise das Ende des Satzes, aber bei Abkürzungen wie bei 'z.B.' steht er nicht zwangläufig am Ende des Satzes, also kann man nicht behaupten, dass es Regel wäre, dass ein Punkt immer nur als Trennzeichen zwischen Sätzen gilt.
Drei aufeinander folgende Punkte sind Zeichen für Auslassung. Ein Komma trennt (u.a.) Nebensätze und Aufzählungen voneinander, oft ist es aber dem Schreibenden überlassen ob er an einer Stelle ein Komma setzt oder nicht oder ob er gar einen Semikolon verwendet.
(Ich habe nur diese Beispiele genommen, weil sie auch in anderen Sprachen als Deutsch exisitieren.)

Was ich damit sagen will ist, dass es nicht ungewöhnlich ist, dass solche Zeichen quasi kontextsensitiv sind. ;-)

Grüße
Thomas

[Tim Tepaße]

Hallo Thomas,

Und wo ist die Fußnote zu 1? ;-)

Ich habe die nervige Angewohnheit hier, Fussnoten in den Signaturen zu verstecken; sollte ich vielleicht mal ändern.

Was ich damit sagen will ist, dass es nicht ungewöhnlich ist, dass solche Zeichen quasi kontextsensitiv sind. ;-)

Ja eben. Dies ist ja auch nicht anders als in der formalen Sprache SGML, das Kleiner-Gleich-Zeichen (">") dient dort je nach Kontext auch einem anderen Zweck. Meine Argumentation geht ja gerade dahin, dass es nervig wäre, Worte in Sprache jeweils nach Wort bzw. Wortart anders zu begrenzen, nur weil man damit Eindeutigkeit gewinnen würde. Stattdessen gibt es das Leerzeichen, die Art eines Wortes ergibt sich aber nicht dadurch, sondern durch den Kontext des Satzes bzw. durch die Schreibweise des Wortes.

Nehmen wir mal als Vergleich das von der ECMAScript Literalschreibweise geerbte Javascript Object Notation. Hier gibt es je nach Datentyp eine unterschiedliche Begrenzungszeichen, für Strings die traditionellen Zollzeichen, für Objekte geschweifte, für Arrays eckige Klammern. Für einem so kleinen Bestand an Datentypen ist es noch merkbar; bei einem größeren Bestand artet es in eine nicht wirklich merkbare Komplexität aus. Man stelle sich eine Programmiersprache vor, in der man nicht nur eigene Datentypen definieren kann, sondern auch für diese eine jeweilige Literalschreibweise. Aua.

Tim