nicht angemeldet molily
molily
molily
Felix Riesterer
Gunnar Bittersmann
molily
molily
Heyho!
ich habe vor einigen Jahren hier mit selfhtml JavaScript gelernt. Auf den Einführungsseiten zu diesem Thema wird empfohlen, für "alte Browser" den JS-Code mit "<!-- ... //-->" zu umschließen - dies sei "gängige Praxis".
Nun hatte ich gerade einen merkwürdigen Fehler mit der prototype-JavaScript-Bibliothek, wo genau diese "<!-- ... //-->" im IE zu Fehlern führten (das genaue Problem erspare ich euch mal, ist jetzt nicht wichtig). Jedenfalls funktioniert alles wenn ich "<!-- ... //-->" weglasse.
Das führt mich nun zu der Frage, inwiefern "<!-- ... //-->" überhaupt noch relevant ist heutzutage? Für den IE2 und Netscape1 programmiert schon längst keiner mehr. JavaScript wird von jedem Browser verstanden oder zumindest nicht fälschlicherweise angezeigt. Und nun scheinen die ersten Probleme genau *wegen* dieser Zeichen zu kommen....
Wie macht ihr das? Benutzt ihr sie? Sollte man sie heutzutage lieber weglassen?
Gruß
Mastershrimp
Wie macht ihr das? Benutzt ihr sie? Sollte man sie heutzutage lieber weglassen?
ich schreibe einfach gar kein JavaScript ins HTML, sondern nutze das src-Attribut um eine separate JavaScript-Datei einzubinden. Damit ist die Frage irrelevant!
Ok, danke euch allen für die schnellen Meinungen!
Ich dachte halt bisher sie würden nicht schaden und im Zweifel nützen...naja, man sollte wohl mit der Zeit gehen bei sowas ;-)
Gruß
Mastershrimp
ich schreibe einfach gar kein JavaScript ins HTML, sondern nutze das src-Attribut um eine separate JavaScript-Datei einzubinden. Damit ist die Frage irrelevant!
Geh' einfach zu Fuß - dann ist die Frage irrelevant, ob du Fahrrad fahren kannst oder nicht ...
Geh' einfach zu Fuß - dann ist die Frage irrelevant, ob du Fahrrad fahren kannst oder nicht ...
das ist nun nicht nur bzgl. der Frage irrelevant sondern einfach ein ziemlich dummer Kommentar.
das ist nun nicht nur bzgl. der Frage irrelevant sondern einfach ein ziemlich dummer Kommentar.
Ich finde deinen Kommentar dumm - warum sollte man eine separate Ressource einbinden, wenn 2 oder 3 Zeilen JavaScript reichen?
Wie macht ihr das? Benutzt ihr sie? Sollte man sie heutzutage lieber weglassen?
Ich perönlich nicht!
<script type="text/javascript"> reicht vollkommen aus.
Wer nutzt denn heute noch IE2 oder NS1^^ ???
Hi,
Wer nutzt denn heute noch IE2 oder NS1^^ ???
Wer nutzt heutzutage noch PHP, mit dessen strip_tags() man an den Content kommt, vorausgesetzt, CSS & JS ist auskommentiert, und damit für *jeden* Client vom eigentlichen Inhalt unterscheidbar ist.
Will sagen: die Fokussierung auf IE2 oder NS1 geht am Problem vorbei, da man nunmal nicht vorhersagen kann, wer oder was mal einen Quelltext bearbeiten soll ...
Gruß, Cybaer
Yerf!
Wer nutzt heutzutage noch PHP, mit dessen strip_tags() man an den Content kommt, vorausgesetzt, CSS & JS ist auskommentiert, und damit für *jeden* Client vom eigentlichen Inhalt unterscheidbar ist.
Leute, die nicht wissen, wie HTML aufgebaut ist? Wer alle Tags aus HTML entfernt und somit jegliche semantische Auszeichnung über Bord wirft braucht sich nicht wundern, wenn er nacher nur Kauderwelsch hat.
Wenn man kein CSS&JS haben will muss man eben den inhalt aus den <script> und <style> Elementen ebenfalls entfernen... Wo ist das Problem?
Gruß,
Harlequin
Hi,
Leute, die nicht wissen, wie HTML aufgebaut ist?
Ach, Kindchen ... >;->
Wer alle Tags aus HTML entfernt und somit jegliche semantische Auszeichnung über Bord wirft braucht sich nicht wundern, wenn er nacher nur Kauderwelsch hat.
Es geht aber nicht um "Kauderwelsch". Und ja: Wenn ein HTML-Dokument seine Tags verliert, sollte es immer noch lesbar sein. Ist übrigens eine der Stärken dieser "Seitenbeschreibungssprache".
Wenn man kein CSS&JS haben will muss man eben den inhalt aus den <script> und <style> Elementen ebenfalls entfernen...
Eigentlich nur SCRIPT, da STYLE im BODY bekanntlich nichts zu suchen hat (gleichwohl: BODY ist ja ggf. optional und beginnt bei der ersten Ausgabe von Daten - was auch Stildefinitionen sein können, wenn das im Lauf der Jahre hinzugekommene Verhalten von HTML 4.01 nicht berücksichtigt wird).
Wo ist das Problem?
In mangelnder Rücksichtnahme auf Abwärtskompatibilität, da niemand weiß, wer oder was in Zukunft einmal darauf zugreifen wird.
Wo ist das Problem, in ein paar wenigen Bytes mehr? Sie sind schneller geschrieben (falls man die überhaupt schreiben muß), als sich Leute hier Gedanken machen (wollen oder können).
Gruß, Cybaer
Yerf!
Es geht aber nicht um "Kauderwelsch". Und ja: Wenn ein HTML-Dokument seine Tags verliert, sollte es immer noch lesbar sein. Ist übrigens eine der Stärken dieser "Seitenbeschreibungssprache".
Da stellt sich die Frage des Stellenwertes von Inline-Scripts. Entweder ist es gewollt, dass sie zum Inhalt gezählt werden oder es ist ein Fehler von HTML Inline-Scripte zu erlauben...
Eigentlich nur SCRIPT, da STYLE im BODY bekanntlich nichts zu suchen hat (gleichwohl: BODY ist ja ggf. optional und beginnt bei der ersten Ausgabe von Daten - was auch Stildefinitionen sein können, wenn das im Lauf der Jahre hinzugekommene Verhalten von HTML 4.01 nicht berücksichtigt wird).
Wobei hierfür bereits ein vorgelagerter Schritt mit zugriff auf die Semantik von HTML notwendig ist: man pickt sich den Inhalt des Body-Elementes heraus. Was spricht dagegen hier zusätzliche Operationen einzubauen?
» Wo ist das Problem?
In mangelnder Rücksichtnahme auf Abwärtskompatibilität, da niemand weiß, wer oder was in Zukunft einmal darauf zugreifen wird.
Ich steh nun mal auf dem Standpunkt, dass man es mit Abwärtskompatibilität auch sehr schnell übertreiben kann. Da schleppt man dann einen riesen Wust an Zusatzkram mit sich rum und verbaut sich neue Ansätze für die Zukunft.
Wo ist das Problem, in ein paar wenigen Bytes mehr? Sie sind schneller geschrieben (falls man die überhaupt schreiben muß), als sich Leute hier Gedanken machen (wollen oder können).
Worin besteht das Problem den parsenden Code anzupassen, dass er <script> ignoriert?
Vor allem, wieso sollte dass das Problem des HTML-Authors sein?
Gruß,
Harlequin
Hi,
Entweder ist es gewollt, dass sie zum Inhalt gezählt werden
Das war nie gewollt, deswegen wurden sie ja von Anfang an auskommentiert.
oder es ist ein Fehler von HTML Inline-Scripte zu erlauben...
Ja, das sehen manche so. Es wird ja auch, aus verschiedenen Gründen, dringend zu externen Scripts (und Stildefinitionen) geraten. Aber es ist, wie es ist ...
Wobei hierfür bereits ein vorgelagerter Schritt mit zugriff auf die Semantik von HTML notwendig ist: man pickt sich den Inhalt des Body-Elementes heraus. Was spricht dagegen hier zusätzliche Operationen einzubauen?
Nichts. Man sollte sich nur nie darauf verlassen, daß eien HTML-Seite genau mit der Konfiguration angesheen/verarbeitet wird, die man selbst sich so vorgestellt hat. Weißt Du, was es alles an Browsern udn Tols so gibt? Weißt Du, was es in Zukunft geben wird? Weiß das irgendjemand?
Ich steh nun mal auf dem Standpunkt, dass man es mit Abwärtskompatibilität auch sehr schnell übertreiben kann. Da schleppt man dann einen riesen Wust an Zusatzkram mit sich rum und verbaut sich neue Ansätze für die Zukunft.
Ja, manchmal ist ein Schnitt sinnvoll oder gar unumgänglich. Von XHTML 1 auf XHTML 1.1 oder gar 2 wäre so einer gewesen (Gott hab ihn selig - jedenfalls für die nächsten Jahre).
Hier handelt es sich jedoch um eine leicht herzustellende Abwärtskompatibilität, die (schon per definitionem) niemandem schadet oder schaden wird.
Worin besteht das Problem den parsenden Code anzupassen, dass er <script> ignoriert?
Vielleicht weil der Anwender keinen Zugriff auf den Code hat, sondern nur eine fertige Applikation?
Vor allem, wieso sollte dass das Problem des HTML-Authors sein?
Er schreibt den Quelltext, und sollte für Trennung des Contents vom Rest sorgen. Und, mittels weniger Bytes, kann er das auch.
Genauso kannst Du fragen: Warum sollte der Autor nach W3C-Standards coden, wenn es auch so funktioniert? Fakt ist, die meisten Seiten im Web sind invalide, und keine Sau stört's. Müssen muß niemand irgendwas. Aber sagen: Vorsicht ist die Mutter der Porzellankiste, niemand hat den Überblick, über ein System, das explizit auf Softwareunabhängigkeit bzw. An- & Aufwärtskompatibilität ausgelegt wurde, das wird man wohl noch dürfen.
Niemand hat unter ein wenig Rücksicht zu leiden ...
Gruß, Cybaer
Yerf!
» Entweder ist es gewollt, dass sie zum Inhalt gezählt werden
Das war nie gewollt, deswegen wurden sie ja von Anfang an auskommentiert.
Was darauf hindeutet, das wir hier ein weiteres Relikt aus der Urzeit von HTML haben, wo schon einiges "suboptimal" gelaufen ist.
Nichts. Man sollte sich nur nie darauf verlassen, daß eien HTML-Seite genau mit der Konfiguration angesheen/verarbeitet wird, die man selbst sich so vorgestellt hat. Weißt Du, was es alles an Browsern udn Tols so gibt? Weißt Du, was es in Zukunft geben wird? Weiß das irgendjemand?
Nein, das weiß sicher keiner... aber wer zwingt jemanden dazu untaugliche Tools zu verwenden und sollte man nicht gegen *die* vorgehen?
(Ich weiß, ich träum gern von einer besseren Welt, aber ist das so falsch?)
Ja, manchmal ist ein Schnitt sinnvoll oder gar unumgänglich. Von XHTML 1 auf XHTML 1.1 oder gar 2 wäre so einer gewesen (Gott hab ihn selig - jedenfalls für die nächsten Jahre).
Schade, aber das wohl das Schicksal der "Besseren", der Masse reicht etwas, das "funzt"... :-(
» Vor allem, wieso sollte dass das Problem des HTML-Authors sein?
Er schreibt den Quelltext, und sollte für Trennung des Contents vom Rest sorgen. Und, mittels weniger Bytes, kann er das auch.
Wobei man auch sagen könnte, dass die Semantik von <script> diese bereits herstellt...
Wobei ich das auch für unsauber halte, an der Stelle ist es einfach besser Skripts grundsätzlich extern oder zumindest im <head> einzubinden.
Niemand hat unter ein wenig Rücksicht zu leiden ...
Das "ein wenig" summiert sich schnell und wird dann doch aufwändig. Erinnert mich auch grad ein wenig an die Diskussion um das Ext4-Dateisystem auf Heise...
Gruß,
Harlequin
@@Harlequin:
Wobei ich das auch für unsauber halte, an der Stelle ist es einfach besser Skripts grundsätzlich extern oder zumindest im <head> einzubinden.
Es spricht einiges dafür, Scripte als letztes im 'body' ainzubinden: Sehr sehr schnelle Seiten - Website Performance Best Practice - Teil 2. Außerdem spart man sich dadurch onload-Eventhandler.
Live long and prosper,
Gunnar
Hi,
Es spricht einiges dafür, Scripte als letztes im 'body' ainzubinden:
Yep! Aber das können natürlich auch externe Script sein. :)
Allerdings ist der Verzicht auf einen weiteren Request natürlich per se performanter - jedenfalls wenn die Bytemenge relativ klein ist.
Gruß, Cybaer
Hi,
Was darauf hindeutet, das wir hier ein weiteres Relikt aus der Urzeit von HTML haben, wo schon einiges "suboptimal" gelaufen ist.
Du meinst, jetzt läuft alles optimal? :)
Nein, das weiß sicher keiner... aber wer zwingt jemanden dazu untaugliche Tools zu verwenden und sollte man nicht gegen *die* vorgehen?
Abwärtskompatibilität ist eines der zwingenden Argumente für HTML. Es ist sogar so zwingend, daß selbst das erste XHTML abwärtskompatibel blieb, und die folgenden, nicht mehr abwärtskompatiblen Versionen fürs erste auf Eis gelegt wurden. Aber das muß dir nicht zu denken geben ... ;->
Und wer davon ausgeht, daß schon jeder updaten wird, weil er updaten kann, und das bei einem System mit garantierter Abwärtskompatibilität, nun ja ...
»» Er schreibt den Quelltext, und sollte für Trennung des Contents vom Rest sorgen. Und, mittels weniger Bytes, kann er das auch.
Wobei man auch sagen könnte, dass die Semantik von <script> diese bereits herstellt...
HTML ist "dumm". Es ist eine "Seitrenbeschreibungssprache". Dinge, die nicht zum Content der Seite gehören, Programme und Stile, gehören ausgeklammert.
Wobei ich das auch für unsauber halte, an der Stelle ist es einfach besser Skripts grundsätzlich extern oder zumindest im <head> einzubinden.
Es ist erlaubt, also kann man Inline-Scripts & -Styles verwenden.
Das "ein wenig" summiert sich schnell und wird dann doch aufwändig.
Wir reden hier aber über ein explizit abwärtskompatibles System, und über eine Sache, die keinerlei Nachteile mit sich zieht.
Gruß, Cybaer
Man sollte sich nur nie darauf verlassen, daß eien HTML-Seite genau mit der Konfiguration angesheen/verarbeitet wird, die man selbst sich so vorgestellt hat. Weißt Du, was es alles an Browsern udn Tols so gibt? Weißt Du, was es in Zukunft geben wird? Weiß das irgendjemand?
Nein, aber das ist kein Argument dafür, irgendwelche willkürlichen Dinge zu tun, weil irgendwann irgendein User-Agent irgendetwas unbekanntes und unvorhergesehenes machen könnte gemäß unbekannten, nirgendwo definierten Regeln. So argumentierst du nämlich. Das ist jedoch Wahnsinn - auf diesen Fall kann man sich nicht vorbereiten.
Realistischer ist, sich an dokumentierte und etablierte Standards, zu halten, damit alle Tools GEMÄSS DIESEN das Dokument bis in alle Ewigkeit problemlos verarbeiten können.
Wenn ein kaputter User-Agent vorbeikommt, kann ich partout nicht auf dessen Fehler vorbereitet sein - es könnten beliebige sein.
Hier handelt es sich jedoch um eine leicht herzustellende Abwärtskompatibilität, die
niemandem nützt.
Genauso kannst Du fragen: Warum sollte der Autor nach W3C-Standards coden, wenn es auch so funktioniert?
Nein, das ist eine ganz andere Sache!
Du spekulierst hier über hypothetische Möglichkeiten, für die man gerüstet sein sollte. Dass ein Programm ein HTML-Dokument nach den HTML-Regeln verarbeitet, ist aber kein hypothetischer Sonderfall.
Fakt ist, die meisten Seiten im Web sind invalide, und keine Sau stört's.
Doch. Und zwar diejenigen, die diese Dokumente verarbeiten. Die wollen klare Regeln, auf die man sich einigt.
Niemand hat unter ein wenig Rücksicht zu leiden ...
Nenn doch mal ein realistischen Fall, in denen die Auskommentierung nützlich ist.
Mathias
Hi,
»» Hier handelt es sich jedoch um eine leicht herzustellende Abwärtskompatibilität, die
niemandem nützt.
Mag sein. My name is nobody. :-)
Dass ein Programm ein HTML-Dokument nach den HTML-Regeln verarbeitet, ist aber kein hypothetischer Sonderfall.
Wenn SCRIPT- und STYLE-Elemente, sowie deren Behandlung, von Anfang an Teil von HTML gewesen wären, würde ich dir ja zustimmen. Sie sind es nicht, sie wurden erst mit 3.2 eingeführt. Du verallgemeinerst, und führst damit, mal wieder, bewußt in die Irre.
»» Niemand hat unter ein wenig Rücksicht zu leiden ...
Nenn doch mal ein realistischen Fall, in denen die Auskommentierung nützlich ist.
Mir hat es schon das Leben einfacher gemacht, beim "Mal-eben-Rausziehen" des Contents (das Beispiel mit strip_tags() in PHP kommt nicht von ungefähr).
Aber das ist nicht der Punkt. Der Punkt ist, daß weder ich noch Du noch sonstwer den totalen Überblick haben kann. Ein HTML-kompatibler UA muß eben nicht zwingend die Besonderheiten von HTML 4 berücksichtigen. HTML wurde bewußt auf- und abwärtskompatibel designt. Ich sehe keinen Grund, das ohne *zwingenden* Grund über Bord zu werfen. Ich lese hier nur: "nicht mehr nötig, weil moderne Browser damit umgehen können". Aber das ist wohl kein *Grund*, eher ein willkommener Anlaß, zur Bequemlichkeit (wobei: *mein* Editor macht die Kommentare auf Wunsch eh automatisch mit).
Gruß, Cybaer
Mir hat es schon das Leben einfacher gemacht, beim "Mal-eben-Rausziehen" des Contents (das Beispiel mit strip_tags() in PHP kommt nicht von ungefähr).
Wenn man mit einer bekanntermaßen unzureichenden Technik ein HTML-Dokument verarbeiten willst, dann ist man selbst schuld, wenn es schief läuft, und kann nicht vom Seitenautor erwarten, dafür Dokumente zur Verfügung zu stellen.
Der Punkt ist, daß weder ich noch Du noch sonstwer den totalen Überblick haben kann.
Doch, ich habe den Überblick über Software, die nur HTML 2 versteht:
Es gibt keine mehr.
Und wer dennoch über 15 Jahre alte Browser verwendet, der wird noch ganz schwerwiegendere Probleme im Web haben, als nicht-auskommentierte Stylesheets und Scripte. Das macht glaube ich nur Cybaer, um zu rechtfertigen, warum man an dieser überkommenden Praxis festhalten sollte. >;-)
Ein HTML-kompatibler UA muß eben nicht zwingend die Besonderheiten von HTML 4 berücksichtigen.
Ein HTML-kompatibler Webautor muss nicht zwingend die Besonderheiten von nicht-HTML-3-kompatiblen UAs berücksichtigen, die praktisch keine Verbreitung mehr finden.
Ich sehe keinen Grund, das ohne *zwingenden* Grund über Bord zu werfen.
Zwingend nicht, aber für UAs zu designen, die faktisch nicht in Gebrauch sind, ist weder vernünftig noch wirtschaftlich.
Ich lese hier nur: "nicht mehr nötig, weil moderne Browser damit umgehen können". Aber das ist wohl kein *Grund*, eher ein willkommener Anlaß, zur Bequemlichkeit
Bequemlichkeit heißt hier konkret Einfachheit, Zeitersparnis und eingesparte Bandbreite.
Mathias
Hi!
Sollte man sie heutzutage lieber weglassen?
Ja, laß die HTML-Kommentare weg.
off:PP
ich habe vor einigen Jahren hier mit selfhtml JavaScript gelernt. Auf den Einführungsseiten zu diesem Thema wird empfohlen, für "alte Browser" den JS-Code mit "<!-- ... //-->" zu umschließen
Wird es nicht.
http://de.selfhtml.org/javascript/intro.htm#javascriptbereiche
Es wird gesagt, dass man dies tun muss, wenn man für IE 2 und Netscape 1 schreiben will. Das ist eine Zweck-Mittel-Aussage, mehr nicht. Wenn man nicht für diese Browser schreiben muss, braucht man dieses »Auskommentieren« nicht.
dies sei "gängige Praxis".
Ja, das ist eine deskriptive Aussage, die eine Tatsache beschreibt.
SELFHTML sagt jedoch, dass »die Browser aus den Anfangstagen des Webs, die JavaScript-Bereiche nicht erkennen können, [...] weitestgehend zu vernachlässigen [sind]«.
Mathias
Jau, da hast du Recht. Ich hatte das einfach immer reingepackt weil ich mir dachte, dass es nicht schade. Lieber ein wenig zu viel berücksichtigen als zu wenig.
Ich werde es ab jetzt raus lassen.
Gruß
Mastershrimp
Lieber Mastershrimp,
da ich gerne XHTML schreibe, notiere ich JavaScript so:
<script type="text/javascript">//<![CDATA[
var JavaScriptCode = "hier";
//]]></script>
Liebe Grüße,
Felix Riesterer.
Hallöchen,
im Gegensatz zur allgemeinen Meinung möchte ich darauf hinweisen, dass man diese "Auskommentierung" nicht grundsätzlich weglassen sollte, da diese für die Validierung z.B. von XHTML sehr wichtig ist:
Moderne Browser verstehen inline-Javascript in XHTML-Dokumenten mit folgendem korrekten Code:
<script type="text/javascript">;
<![CDATA[
// Hier viel Javascript ....
]]>
</script>
Dem Validator wird mitgeteilt, dass es sich im CDATA-Tag um Text (Character Data) handelt welcher nicht als XHTML anzusehen ist. Laut DTD wird ohne diese Angabe nämlich standardmäßig PCData angewandt, was für Parsed Character Data steht. Der Nachteil von PCDATA besteht nun darin, dass XHTML-Tags im Kontext validiert werden und man dadurch genötigt ist jedes Tag zu entwerten (z.B. per Umschreibung als < für < oder per Escapen der Zeichen mit einem Backslash (). Diese Entwertung entfällt bei der Angabe als CDATA und validiert einwandfrei.
Da nun aber einige ältere Browser diesen Tag nicht verstehen (und Javascript-Fehler werfen) wird es für sie einfach auskommentiert:
<script type="text/javascript">
/* <![CDATA[ */
// Hier ganz viel Javascript
/* ]]> */
</script>
Das Dokument validiert wie gewünscht, da die Kommentarzeichen für den Validator keine Bedeutung haben, und auch ältere Browser die XHTML nicht verstehen und alles als HTML parsen, interpretieren das Javascript korrekt.
Allerdings gebe ich meinen Vorrednern Recht: Das Auskommentieren mithilfe des <!-- ... //>-Tags sollte für die Zukunft (Browser, die sich strickt an XHTML halten und derartige Kommentare komplett NICHT mehr ausführen) vermieden werden.
gruß
cross
@@cross:
im Gegensatz zur allgemeinen Meinung möchte ich darauf hinweisen, dass man diese "Auskommentierung" nicht grundsätzlich weglassen sollte […]
Allerdings gebe ich meinen Vorrednern Recht: Das Auskommentieren mithilfe des <!-- ... //>-Tags sollte für die Zukunft […] vermieden werden.
Du widersprichst dir. Genau um diese Auskommentierung ging es hier, nicht um die Auskommentierung von "<![CDATA[" und "]]>".
/* <![CDATA[ */
// Hier ganz viel Javascript
/* ]]> */
Wie in Felix’ Posting zu sehen ist, bieten sich <http://de.selfhtml.org/javascript/sprache/regeln.htm#kommentare@title=einzeilige Kommentare> an.
Live long and prosper,
Gunnar
Du widersprichst dir. Genau um diese Auskommentierung ging es hier, nicht um die Auskommentierung von "
<![CDATA[" und "]]>".
Das widerspricht sich imho keineswegs, denn es geht nicht ausschließlich um <!-- .. //-->, sondern um <!-- .. //--> im ZUSAMMENHANG mit Javascript und das sollte in Bezug auf valides HXTML sehr wohl "auskommentiert" werden, nämlich mit besagtem CDATA, statt mit <!-- .. //-->.
Da aber ältere Browser diesen Tag ( <![CDATA[ ... ) möglicherweise nicht verstehen, kann man das <![CDATA[ selbst nochmal auskommentieren, nämlich mit besagtem /* <![CDATA[ */ ... /* ]]> */
Sicherlich hast Du (Ihr) recht, dass man auf <!-- ... //--> in Bezug auf Javascript verzichten sollte.
Meiner bescheidenen Meinung nach ist das dem OT nicht klar genug rübergebracht worden. Vermutlich meint er jetzt, dass sowas wie dieses:
<script type="text/javascript">
$("myText").setHTML("<p>Hallo</p>");
</script>
gültig ist. Diese Schreibweise wird einen Error im XHTML-Validator verursachen!
MfG
cross
Da aber ältere Browser diesen Tag ( <![CDATA[ ... ) möglicherweise nicht verstehen, kann man das <![CDATA[ selbst nochmal auskommentieren, nämlich mit besagtem /* <![CDATA[ */ ... /* ]]> */
Siehe mein anderes Posting.
Meiner bescheidenen Meinung nach ist das dem OT nicht klar genug rübergebracht worden. Vermutlich meint er jetzt, dass sowas wie dieses:
<script type="text/javascript">
$("myText").setHTML("<p>Hallo</p>");
</script>
> gültig ist. Diese Schreibweise wird einen Error im XHTML-Validator verursachen!
Richtig. Aber frage dich doch einmal, warum sie nicht auch im Browser einen Fehler auslöst. Und warum <
Da nun aber einige ältere Browser diesen Tag nicht verstehen
Das verstehst du etwas falsch.
Kein Browser versteht CDATA - wenn das XHTML-Dokument als Tag-Soup geparst wird. Auch neuere Browser nicht.
Neuere Browser verfügen durchaus über XML-Parser, aber sie benutzen den zur Verarbeitung von XHTML-Dokumenten nicht, wenn sie diese als Tag-Soup parsen. Das ist üblicherweise der Fall, wenn XHTML als text/html ausgeliefert wird. CDATA wird aber nur in »echtem XHTML«, das als XML verarbeitet wird, von ihnen erkannt.
Man muss CDATA nicht verstecken, weil es ältere Browser gibt, sondern weil man XHTML als text/html (sogenanntes HTML-kompatibles XHTML) ausliefert.
auch ältere Browser die XHTML nicht verstehen und alles als HTML parsen, interpretieren das Javascript korrekt.
Das hat mit älteren Browsern nichts zu tun, sondern nur damit, ob das XHTML als Tag-Soup oder XML geparst wird.
Solange man XHTML als Tag-Soup verarbeiten lässt (und sei es nur in den User-Agents, die kein echtes XHTML können), wird auch diese Auskommentierung nötig sein.
Das Auskommentieren mithilfe des <!-- ... //>-Tags sollte für die Zukunft (Browser, die sich strickt an XHTML halten und derartige Kommentare komplett NICHT mehr ausführen) vermieden werden.
XML-Parser können Kommentare entfernen, müssen es aber nicht.
Mathias
@@molily:
Man muss CDATA nicht verstecken, weil es ältere Browser gibt, sondern weil man XHTML als text/html (sogenanntes HTML-kompatibles XHTML) ausliefert.
??
Ich glaube, da war cross mit „Da nun aber einige ältere Browser diesen Tag ["<![CDATA[" und "]]>"] nicht verstehen (und Javascript-Fehler werfen) wird es für sie einfach auskommentiert“ näher dran.
Man muss "<![CDATA[" und "]]>" auskommentieren, weil der Inhalt des 'script[@type="text/javascript]'-Elements als JavaScript interpretiert wird und "<![CDATA[" und "]]>" kein JavaScript-Code ist.
Wenn die JavaScript-Engines einiger Browser bei nicht auskommentierten "<![CDATA[" und "]]>" keinen Fehler werfen, dann ist das deren Fehlertoleranz zu verdanken.
Zu "<!--" und "-->":
Die HTML-Spec sagt: „Einige Skript-Engines, einschließlich der Engines für die Sprachen JavaScript, VBScript und Tcl, gestatten die Angabe der Skriptzeilen in SGML-Kommentaren.“ [HTML401 §18.3.2]
Allerdings finde ich das in keiner JavaScript-Spec festgeschrieben (im Gegensatz zu "<!--" und "-->" in CSS). Ist das auch nur Fehlertoleranz der JavaScript-Engines der Browser?
Live long and prosper,
Gunnar
Lieber Gunnar,
(im Gegensatz zu "
<!--" und "-->" in CSS)
selbst CSS würde ich - wenn überhaupt - mit <![CDATA[ einklammern. Da CSS innerhalb von HTML gut als Elementinhalt verträglich notierbar ist (bis auf den Kindselektor keine kritischen Zeichen) kann man oft darauf verzichten.
Was ältere Browser so machen ist von den Benutzern explizit so gewollt, denn sonst würde kein NS4 (oder älter) oder IE4 (oder älter) laufen!
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer:
(bis auf den Kindselektor keine kritischen Zeichen)
'>' dürfte nicht kritisch sein (im Gegensatzt zu '<').
Kritisch könnten aber selbst vergebene Bezeichner (IDs, Klassen), Attributwerte in Attributselektoren, Werte der 'content'-Eigenschaft etc. sein.
Live long and prosper,
Gunnar
Moin Moin!
Was ältere Browser so machen ist von den Benutzern explizit so gewollt, denn sonst würde kein NS4 (oder älter) oder IE4 (oder älter) laufen!
Einspruch: Wir haben irgendwann um 2000/2001 herum, als der IE6 halbwegs aktuell war, einen Kunden aus der Finanzbranche gehabt, dessen IT darauf BESTAND, einen Netscpae 4.x einzusetzen, mit x deutlich unter 78. Alle Hinweise, dass diese Aniquität für unser Produkt nicht wirklich brauchbar ist (Anforderung: IE5+, FF1+, NN6+), wurden mit dem netten Wort "Policy" erschlagen. Die Darstellung war natürlich unter aller Sau, glücklicherweise habe ich damals Javascript nur sehr sparsam eingesetzt, so dass alle Funktionen trotzdem verfügbar waren. Ich meine, irgendwann hätte man einen armen Sklav--äh--Praktikanten darauf angesetzt, die Templates einigermaßen NN4-tauglich zu machen.
Wahrscheinlich müssen sich die armen Schweine noch heute mit dem NN4 herumschlagen und sind somit die letzte Bastion dieser Antiquität.
Alexander
Lieber Alexander,
Einspruch: Wir haben irgendwann um 2000/2001 herum
wir schreiben das Jahr 2009. Mit einer "9" am Ende! Das ist also acht Jahre her!
einen Kunden aus der Finanzbranche gehabt, dessen IT darauf BESTAND, einen Netscpae 4.x einzusetzen, mit x deutlich unter 78.
Wie gesagt, die wollten das _explizit_ so haben.
Alle Hinweise [...] wurden mit dem netten Wort "Policy" erschlagen.
Wie gesagt, die _wollten_ das _explizit_ _so_ haben. Und wer sind wir, dass wir uns solchen Wünschen verweigern? Dass dann nicht alles unbedingt so wie erwartet tut oder aussieht, sei ja - und ich wiederhole mich versprochenermaßen zum letzten Mal - explizit so gewollt.
Liebe Grüße,
Felix Riesterer.
Moin Moin!
»» Alle Hinweise [...] wurden mit dem netten Wort "Policy" erschlagen.
Wie gesagt, die _wollten_ das _explizit_ _so_ haben.
Wohl eher ein inkompetenter Hohlkörper in ausreichen hoher Unternehmensposition. Die Mitarbeiter wären über einen brauchbaren Browser sicherlich glücklich gewesen.
Alexander
Lieber Alexander,
Wohl eher ein inkompetenter Hohlkörper in ausreichen hoher Unternehmensposition.
und der kam da zufällig hin, oder hat den jemand explizit dort haben wollen?
Liebe Grüße,
Felix Riesterer.
Moin Moin!
»» Wohl eher ein inkompetenter Hohlkörper in ausreichen hoher Unternehmensposition.
und der kam da zufällig hin, oder hat den jemand explizit dort haben wollen?
Ganz klar: Die gesamte Belegschaft hat den demokratisch gewählt. ;-)
Ich vermute mal eher Peter-Prinzip.
Alexander
Ich glaube, da war cross mit „Da nun aber einige ältere Browser diesen Tag ["<![CDATA[" und "]]>"] nicht verstehen (und Javascript-Fehler werfen) wird es für sie einfach auskommentiert“ näher dran.
Nein, das hat mit älteren Browsern überhaupt nichts zu tun!
Auch neuere Browser tun dies, wenn sie Tag-Soup parsen. Aber auch nur dann.
Man muss CDATA nicht verstecken, weil es ältere Browser gibt, sondern weil man XHTML als text/html (sogenanntes HTML-kompatibles XHTML) ausliefert.
... weil ansonsten in diesem Fall ...
der Inhalt des 'script[@type="text/javascript]'-Elements als JavaScript interpretiert wird
Habe ich etwas anderes behauptet? Ich denke nicht, dass sich diese Aussagen widersprechen, sondern vielmehr ergänzen.
Meine Aussage war: In XHTML muss man dies *nur dann* tun, wenn man das XHTML nicht als XML verarbeiten lässt.
Warum? Weil dann Tag-Soup-Regeln gelten und der Parser das CDATA nicht als solches erkennt. <![CDATA[ und ]]> werden daher als ganz normale Zeichendaten erkannt, im Dokument belassen, als Teil des script-Elementinhaltes gewertet und schließlich an den JavaScript-Parser übergeben.
Das hatte cross einfach durcheinander gebracht: Mit alten Browsern hat das nichts zu tun.
Wenn das Dokument nämlich als XML geparst wird, wie es bei XHTML eigentlich vorgesehen ist, dann bekommt der JavaScript-Interpreter von dem CDATA überhaupt nichts mit. Das ist ja Sinn von CDATA, die Anwendung, an die das geparste Dokument durchgegeben wird, hat sich weder für CDATA-Abschnitte noch für Entities oder Zeichenreferenzen zu interessieren.
Wenn die JavaScript-Engines einiger Browser bei nicht auskommentierten "
<![CDATA[" und "]]>" keinen Fehler werfen, dann ist das deren Fehlertoleranz zu verdanken.
Es gibt m.W. keinen Browser, der keine Fehlermeldung wirft.
Allerdings finde ich das in keiner JavaScript-Spec festgeschrieben
Ist es auch nicht. Die Aussage im HTML-Standard beschreibt bloß den Usus.
Mathias