It is common practice when including inline scripts within HTML markup, to\r\n\tsurround the entire script within what appears to be an HTML comment like this:<\/p>\r\n\r\n
<script type=\"text\/javascript\"><!--\r\n ...\r\n\/\/--><\/script> <\/code><\/pre>\r\n<\/div>\r\n\r\nThis technique is discussed in HTML 4.01, section 18.3.2 Hiding\r\n\t\tscript data from user agents<\/a>. However, few people really understand its purpose, what it\r\n\treally is, the problems it creates within XHTML documents, nor the theoretical\r\n\tproblems it creates for HTML.<\/p>\r\nIn this article, the term legacy user agents<\/dfn>, legacy UAs<\/dfn> (or\r\n\tequivalent) is used to refer only to user agents implemented before the script<\/code>\tand style<\/code> elements\r\n\twere introduced as place holders in HTML 3.2<\/a>.<\/p>\r\nNote: Although this document will be primarily focussing on the script<\/code> element,\r\n\tthe concepts presented apply equally to the style<\/code> element as well.<\/p>\r\n\r\nPurpose of the Comment<\/h3>\r\n
The purpose of the comment is to allow documents to degrade gracefully in\r\n\tlegacy user agents by preventing them from outputting the script as content\r\n\tfor the user to read. Since HTML user agents output the content of any unknown\r\n\telements and because it would be unwise to do so for a script, the use of the\r\n\tcomment is designed to ensure that this does not occur within legacy user agents.<\/p>\r\n
It should be noted that there are no user agents in use today that don\u2019t support\r\n\tthe script<\/code> element (regardless of whether they support the actual\r\n\tscript or not), so using this technique on the web today seems rather superfluous.\r\n\tYet it\u2019s interesting to note that so many sites still make use of this old technique\r\n\tthat was designed for accessibility reasons, despite the fact that so many\r\n\tof these sites choke in many other ways in browsers with scripts disabled or\r\n\tunsupported.<\/p>\r\n\r\nIt\u2019s Not Really a Comment<\/h3>\r\n
The content model of the script<\/code> element in HTML is declared as CDATA<\/code>, which\r\n\tstands for character data and means that the content within the element is not\r\n\tprocessed as markup, but as plain text. The only piece of markup which is recognised\r\n\tis the end-tag open (ETAGO<\/code>) delimiter: <\/<\/code>. Where the ETAGO<\/code> occurs, it must\r\n\tbe for the element\u2019s end-tag ( <\/script><\/code> in this case). This is actually\r\n\tthe cause of a really common\r\n\tvalidation error in scripts<\/a> for people that use\r\n\tthe document.write()<\/code> function or the innerHTML<\/code> property.<\/p>\r\nBecause no other markup is recognised, the comment declaration is not really\r\n\ta comment; but rather plain text that looks like a comment. It\u2019s designed for\r\n\tlegacy UAs that don\u2019t read the DTD and are, therefore, unaware that the script\r\n\telement actually contains CDATA<\/code>. Because it is designed for backwards compatibility\r\n\twith legacy UAs processing it as markup, there are certain considerations that\r\n\tshould be made as a result of this.<\/p>\r\nThere are two small theoretical problems which most people are unaware of\r\n\tbut, since no browser has ever been a strictly conforming SGML parser, neither\r\n\tof which are of any practical concern. As you will see, it is in fact the bugs\r\n\tin the legacy UAs for which this technique is designed, that ensures it always\r\n\tworks as intended.<\/p>\r\n
For legacy browsers encountering the unknown script<\/code> element, they may or may\r\n\tnot know the content model, depending on whether or not they\u2019ve read the DTD\r\n\tor obtained the information from elsewhere.<\/p>\r\nIn the case of the unknown content model, the parser would treat the element\u2019s\r\n\tcontent as markup and hide the comment as expected, in most cases. However,\r\n\tthere may be a problem caused by the presence of two hyphens within the script\r\n\tthat is contained within the comment. Consider the following example:<\/p>\r\n\r\n
\r\nExample 2:<\/h4>\r\n<script type=\"text\/javascript\"><!--\r\n var i;\r\n for (i = 10; i > 0; i--) {\r\n \/\/ do something\r\n }\r\n \/\/--><\/script><\/code><\/pre>\r\n <\/div>\r\n \r\nAlthough that is perfect valid HTML 4.01, given that it is not really a comment,\r\n\tthis creates a problem for a legacy user agent that process that as a comment.\r\n\tA comment delimiter in SGML is a pair of hyphens (--<\/code>) and only white\r\n\tspace may occur between the second comment delimiter and markup declaration\r\n\tclose (MDC<\/code>) delimiter: ><\/code>. See the WDG\u2019s\r\n\texplanation of HTML comments<\/a> for more\r\n\tinformation.<\/p>\r\nFor an SGML parser treating the element\u2019s content as markup, the invalid comment\r\n\tsyntax may potentially cause a problem and result in part of the script being\r\n\toutput. As we will see later, this example will actually cause a fatal error\r\n\tin XHTML documents.<\/p>\r\n
In the case of the known content model, since the parser is aware that the\r\n\tcontent model is CDATA<\/code>, yet the script<\/code> element is still an unknown element for\r\n\tthe UA, it would process it as such and actually end up outputting the entire\r\n\tcontent of the element as text, thus defeating the purpose of attempting to\r\n\thide the script.<\/p>\r\nFor backwards compatibility, legacy UAs processing the element\u2019s content as\r\n\tmarkup is depended upon to hide the content, but for the above reasons it\r\n\tmeans that it does not allow for backwards compatibility with any hypothetical\r\n\tlegacy user agent using a strictly conforming SGML parser, in all cases.\r\n\tHowever, there are no browsers that do read the DTD and due to the bugs in\r\n\tall real legacy browsers, neither of these issues have ever caused any real\r\n\tworld problems in HTML. It will also never cause any problem in the future\r\n\teither, since all future implementations will support the script<\/code> element.<\/p>\r\n\r\nXHTML Problems<\/h3>\r\n
This technique does in fact cause real problems for XHTML documents that many\r\n\tauthors are unaware of. It seems that Microsoft have fallen into this trap with\r\n\ttheir new Visual Web Developer 2005 Express application, as discussed by Charl\r\n\tvan Niekerk<\/a> in ASP.NET\r\n\t2.0 \u2013 Part 2<\/a>. It also seems that the Movable\r\n\tType<\/a> developers\r\n\thave made this mistake too, as Jacques\r\n\tDistler pointed out<\/a> recently.<\/p>\r\nIn XHTML, the content model of the script<\/code> element is declared as #PCDATA<\/code> (parsed\r\n\tcharacter data), not CDATA<\/code>, thus the content of the script<\/code> element is supposed\r\n\tto be parsed as markup and the comment declaration really is a comment. Because\r\n\tof this, XHTML UAs will (when the document is served as XML) ignore the content\r\n\tof the comment, and thus ignore the script entirely.<\/p>\r\n