Should I use "]]>" or "//]]>" for closing a CDATA section into xHTML

Question

I want to inline scripts or CSSs into XHTML without escaping special characters.

I can do that using a CDATA marked section.

According to http://www.w3.org/TR/xhtml1/#h-4.8 the CDATA section can be defined as:

   <script type="text/javascript">
      <![CDATA[
         ... unescaped script content ...
      ]]>
   </script>

Then, according to http://www.w3schools.com/TAGS/tag_script.asp, the CDATA can look like:

   <script type="text/javascript"><![CDATA[
     // some code
   //]]></script>

Which method for closing the CDATA section is better? ]]> or //]]> ?

Answer 1

According to www.w3.org/TR/xhtml1/#h-4.8 the CDATA section can be defined as: [no //]

Yeah. In XHTML, they can. Proper XHTML, as read by an XML parser like when you serve application/xhtml+xml to a web browser that isn't IE.

But probably you're actually serving as text/html, which means your browser isn't an ‘XML processor’ as referenced in that section. It's a legacy-HTML4 parser, so you have to abide by the appendix C guidelines and avoid any XML features that don't work in HTML4.

In particular, the strings <![CDATA[ and ]]> in a <script> or <style> block are not special to an HTML4 parser, because in HTML4 those two elements are ‘CDATA elements’ where markup doesn't apply (except for the </ ETAGO sequence to end the element itself). So an HTML4 parser will send those strings straight to the CSS or JavaScript engine.

Because <![CDATA[ is not valid JS, you'll get a JavaScript syntax error. (The other answers are wrong here: it's not just very old browsers, but all HTML4 browsers, that will give errors for an uncommented CDATA section in script.)

You use the // or /* comment markup to hide the content from the JavaScript or CSS engine. So:

<script type="text/javascript">//<![CDATA[
    alert('a&b');
//]]></script>

(Note the leading //; this was omitted in the W3Schools example code, and makes that example code not work at all. Fail. Don't trust W3Schools: they are nothing to do with W3C and their material is often rubbish.)

This is read by an HTML parser as:

• Open-tag script establishing CDATA content until the next ETAGO
• Text //<![CDATA[\n alert('a&b');\n//]]>
• ETAGO and close-tag script
• -> resultant content sent to JavaScript engine: //<![CDATA[\nalert('a&b');\n//]]>

But by an XML parser as:

• Open-tag script (no special parsing implications)
• Text content //
• Open CDATA section establishing CDATA content until the next ]]> sequence
• Text \n alert('a&b');\n//
• Close CDATA section
• Close-tag script
• -> resultant content sent to JavaScript engine: //\nalert('a&b');\n//

Whilst the parsing process is quite different, the JS engine ends up with the same effective code in each case, as thanks to the //​s the only difference is in the comments.

Note this is a very different case to the old-school:

<script type="text/javascript"><!--
    alert('a&b');
//--></script>

which was to hide script/style content so that it didn't get written onto the page in browsers that didn't understand <script> and <style> tags. This will not generate a JavaScript/CSS error, because a hack was put it at a different level: it is a syntactical feature of the CSS and JavaScript languages themselves that <!-- is defined to do nothing, allowing this hack to work.

Those browsers are ancient history; you absolutely should not use this technique today. Especially in XHTML, as an XML parser would take you at your word, turning the whole script block into an XML comment instead of executable code.

I want to inline Scripts or CSSs into xHTML without escaping special characters.

Avoid doing this and you will be much happier.

Do you really need the < and & characters in a <style>? No, almost never. Do you really need them in <script>? Well... sometimes, yeah, and in that case the commented-CDATA-section is acceptable.

But to be honest, XHTML compatibility guideline C.4 is as applicable to HTML4 as it is to XHTML1: anything non-trivial should be an in external script, and then you don't have to worry about any of this.