CDATA comments
Why to use them at all? Just to get a page that contains some on-page script validated...?
Usage of CDATA comments
<style type="text/css"> /*<![CDATA[*/ ... ... ... /*]]>*/ </style> <script type="text/javascript"> //<![CDATA[ ... ... ... //]]> </script>
Notes to "CDATA comments"
Do not leave JavaScript tags empty like this: <script type="text/javascript"></script>
It should look like this: <script type="text/javascript">//<![CDATA[//]]></script>
If a script tag contains a src attribute, the element must be either empty or contain only script documentation. That means, leave <script src="foo.js" type="text/javascript"></script> empty.
Stories about "CDATA comments"
Default cdata and javascript.
I have a bit of javascript that I'd like to hide from the validator.
If I want to validate the page as I'm working on it I won't have to wade through the 47 errors the validator thinks it sees in the javascript where I'm assembling bits of html.
What validator are you using? In HTML (but not XHTML), the content of a script element is already considered CDATA, so the validator shouldn't complain about HTML fragments in the script.
You are using at least some xhtml if you are using the CDATA comments. CDATA is part of xml that may be used in xhtml. You would be allowed to use CDATA only if your page has an xhtml Doctype. If you get a lot of errors at the W3C validator in the script that are xml errors in xhtml, but not errors in html, you may use CDATA comments to hide the script from an xhtml page, and a page then will validate at the W3C with the proper xhtml Doctype. You can avoid this whole problem by using an external script rather than one on the main page. There are a few things in script on even an html page that must be avoided to prevent validation errors. These are discussed at the w3c, and if you make such an error, the validator in the most complete mode often will tell you where to find information about the error. Some such errors cause no harm and mainly are formal errors. However some such errors may cause problems on some browsers and should be avoided.
Actually, it's more complicated than that. For XHTML, all you need is <![CDATA[ and ]]>. However, typical HTML parsers don't understand <![CDATA[ and will throw an error if it is inside a script or style element. So we have to resort to a hack:
starting line: <!--//--><![CDATA[//><!--
ending line: //--><!]]>
This is how it works:
Remember how HTML parsers ignore the first line in a script element if it starts with "<!--"? That would prevent HTML parsers from seeing the "<![CDATA[". However, that type of trick doesn't work in XHTML and would in fact prevent the script from being executed. So we need to end the comment ("-->") before the "<![CDATA[", but if we do that, than the "<![CDATA[" would no longer be hidden to some HTML parsers. So inside the comment, we add "//" that the XHTML parser will ignore (since it really ignores everything inside comments) and most HTML parsers will allow their JS parsers to comment out the rest of the line, including the "<![CDATA[".
So: <!--//--><![CDATA[
Most modern browsers would actually work with just "<!-- -->", since the "<!--" itself would comment out the whole line, but not all HTML parsers are like that.
But what about legacy browsers that don't support Javascript? In this case, the goal is to make sure the script internals aren't displayed. Since they don't support the "<!--" whole line commenting, the "<![CDATA[" is again visible. Next trick: turn the "<![CDATA[" into a "processing instruction" tag (<!foo>), which won't be recognized nor outputted. "<![CDATA[>" would hide it from legacy browsers. However, it wouldn't work with XHTML, since it would consider the ">" to be the first character of the script. So replace that with "//>" so it would ignore that ">" and the rest of the line: "<![CDATA[//>". Finally, add the "<!--" to the end to hide the rest of the script from legacy browsers.
So: <!--//--><![CDATA[//><!--
The ending part goes along the same lines. XHTML parsers needs the "]]>", but HTML parsers don't understand that (and the JS parser would throw an error). So that needs to be commented out with "//".
So: //]]>
Now to support legacy browsers. They need "-->" somewhere. It can't go after the "]]>" since the XHTML parser will see an comment end without a comment start. That could be solved by using the "<!-- -->" trick, but there's a more elegant solution. Add the "-->" before the "]]>" and make the "]]>" into a processing instruction tag to hide it: "--><!]]>". Also, the "<!-- -->" would actually fail for a fully compliant HTML parser that doesn't support JS since its actually the "--" that toggles off/on comments, not the "<!--"/"-->", and the whole comment would be like: "<!-- ...script stuff here... //]]><!-- -->", which has 3 "--"'s. However, to avoid going into that esoteric stuff, just stick with "--><!]]>".
So: //--><!]]>
BTW, if you don't care about legacy browsers, you can just use this:
starting line: <!--//--><![CDATA[
ending line: //]]>
Legacy browser - A legacy browser is an older version of a Web browser—for example, Netscape 3 and Internet Explorer 3 are both considered legacy browsers.
2009
Web Development - XHTML CSS JavaScript jQuery.