Script, style and backwards compatibility

[Jarvklo]

Quick question:
What's the status on backwards compatibility "commenting" syntax (i.e.
<!-- --> and <![CDATA[ ]]>) inside <script type="text/javascript"> and <style type="text/css"> elements in (X)HTML5?

[wgabrie]

In the html 5 spec, section 1.4.1 HTML vs XHTML there are three ways to serve html 5.

1. DOM5 HTML (I have no idea)
2. HTML 5 (text/html)
3. XHTML 5 (application/xhtml+xml)

Comments that contain the string "-->" can be represented in "DOM5 HTML" but not in "HTML5" and "XHTML5".

This makes no sence to me. If HTML 5 (text/html) is going to be backwards compatible with previous HTML versions than why make comment strings only usable in DOM html (whatever that is)?


Update:

In another part of the spec I found this:

8.2.4.1 Initial phase
...
As far as parsing goes, the quirks I know of are:
...
The following is considered one script block (!):
<script><!-- document.write('</script>'); --></script>

I don't know if that is good or bad news.

[zcorpan]

Quick question:
What's the status on backwards compatibility "commenting" syntax (i.e.
<!-- --> and <![CDATA[ ]]>) inside <script type="text/javascript"> and <style type="text/css"> elements in (X)HTML5?

Currently in the HTML5 parsing spec, script and style are parsed as "CDATA" elements (yet another meaning for CDATA, actually ), meaning that < is treated as data unless it's the start of a matching end tag, and & is always treated as data. This behavior is compatible with browsers but error handling is not quite compatible with SGML (in SGML, "</foo" would terminate the element even if it didn't match the start tag).

This means that the following HTML:

Code: Select all

<style><!-- --></style>

...is exactly equivalent to this XHTML:

Code: Select all

<style>&lt;!-- --&gt;</style>

i.e., the strings "<!--" and "-->" are passed on to the CSS processor, which works because they are part of the CSS core syntax.

In case of <script>, the strings are passed on to the scripting engine, and the JS engine knows to ignore the first line if it starts with "<!--", it doesn't know about "-->" which thus has to be commented out or it will be a a JS syntax error.

CDATA sections can be used in XML (as per the XML spec) but not in text/html. Using them in <style> or <script> in text/html will result in the strings being passed on to the CSS processor or script engine, respectively, and they will be syntax errors. Using them outside style or script (e.g. in a <div>) will result in a "bogus comment", effectively equivalent to

Code: Select all

<!--[CDATA[ ]]-->

http://wordsandpictures.dyndns.org/html5/parsetree.html can be used to test html5lib's implementation of the HTML5 parsing spec.

HTH,

[zcorpan]

In the html 5 spec, section 1.4.1 HTML vs XHTML there are three ways to serve html 5.

1. DOM5 HTML (I have no idea)
2. HTML 5 (text/html)
3. XHTML 5 (application/xhtml+xml)

You cannot serve a DOM tree over the wire. The DOM is the browser's in memory representation of the document, which might come from script, or from parsing text/html, or from parsing XML. HTML5 (the language) is defined in terms of the DOM; HTML5 (text/html) and XHTML5 (XML) are serialization forms of that language. Any serialization format that can represent a tree could possibly represent an HTML5 document just like XML can, for instance you could imagine JSON or SGML, but their usefulness in practice is questionable.

You could also imagine other in memory representation models other than DOM, and indeed there exist such models, e.g. XOM, JDOM and DOM4J, but today's browsers use the W3C DOM as their model, and lots of scripts on the web assume that the W3C DOM is used.

Comments that contain the string "-->" can be represented in "DOM5 HTML" but not in "HTML5" and "XHTML5".

This makes no sence to me. If HTML 5 (text/html) is going to be backwards compatible with previous HTML versions than why make comment strings only usable in DOM html (whatever that is)?

The HTML5 spec only observes that it is possible for the DOM (that is defined in another spec) to contain comments with "-->" as data, and such a comment can't be serialized to HTML or XML (but could perhaps be serialized to say JSON), since that would represent the end of the comment. To end up in this situation in practice you would have a script to modify the DOM like so:

Code: Select all

var comment = document.createComment(" foo --> bar ");
document.body.appendChild(comment);

...and then serialize that, e.g.

Code: Select all

alert(document.body.innerHTML);

Update:

In another part of the spec I found this:

8.2.4.1 Initial phase
...
As far as parsing goes, the quirks I know of are:
...
The following is considered one script block (!):
<script><!-- document.write('</script>'); --></script>

I don't know if that is good or bad news.

It's ugly, but it is what browsers do (IIRC, only Gecko in standards mode doesn't do this), and if content relies on it (probably likely), it would have to be specced. (I have some test cases on this. Also see http://lists.whatwg.org/pipermail/whatw ... 06932.html)

[Jarvklo]

Thanks for the explanation zcorpan.
The problem is, even based on this excellent information I still can't find the sections in the spec that describes this clearly (and that's the main reason I (mis)placed this post in the "Feedback on the specs" section originally )

Are there any plans for a (non-normative perhaps?) section that clarifies this as clearly as for instance http://www.w3.org/TR/html4/interact/scr ... l#h-18.3.2 does for HTML4?

[zcorpan]

The problem is, even based on this excellent information I still can't find the sections in the spec that describes this clearly

I think the only text about this in the spec currently that applies to authors is

CDATA elements can have text, but the text must not contain the two character sequence "</" (U+003C LESS-THAN SIGN, U+002F SOLIDUS).

-- http://www.whatwg.org/specs/web-apps/cu ... k/#writing

Are there any plans for a (non-normative perhaps?) section that clarifies this as clearly as for instance http://www.w3.org/TR/html4/interact/scr ... l#h-18.3.2 does for HTML4?

Could you elaborate on what you want the spec to say? (Do you want guidelines for authors as to how they should write their inline scripts and style sheets?)

[Jarvklo]

Hmm...

Small things like the commenting practices of scripts in HTML4/XHTML1 versus how things are designed for WA1 IMHO create compatibility questions between versions ("let's see - how are things in this brave new markup world?"). I personally think that this is true even when there is very little or no difference between HTML versions and I think more people like me might turn to the specs to find out how things are supposed to work.

So IMHO as much of these type of details you can cram in there the better.

That said - You *could* simply link to the "script content description mentioning Javascript" to the passage in the HTML4 recommendation i referenced in my previous post (that would be similar to the way you reference RFC2046 in the definition of the type attribute) if you don't want "guidelines" in the spec.
Or better yet - reference a document specifying that that is the way script parsers and style language parsers are supposed to handle HTML-type comments in Javascript / CSS (if there is such a document )

[zcorpan]

Ok. I'm not quite sure that I understand your request still, however I've drafted the following text which could perhaps be inserted as a note in the "Writing HTML documents" section somewhere...

Old browsers that don't understand the style or script elements (introduced in HTML 3.2) will attempt render their contents. However, the strings "<!--" and "-->" are part of the CSS syntax, and "<!--" is equivalent to "//" in JavaScript, so authors who don't want to reveal their style sheets or scripts to users with such browsers can simply comment them out. [CSS21] [ECMA262]

Code: Select all

<style>
<!--
...
-->
</style>

Code: Select all

<script>
<!--
...
//-->
</script>

(ECMAScript 262 doesn't define <!-- as being a comment, but hopefully it will be fixed when it is updated.)

Is that what you meant?

[Jarvklo]

Yep.
That, and some additional information about how the <!-- commenting practice by nescessity must be handled differently by authors using XHTML5

One reasons I took this up in the first place was that I (very briefly) assumed that since the <!-- issue wasn't handled (or even mentioned) in the WA1-spec it was gone.

Again - the spec is where some of us go to find out how things are supposed to work. IMHO making sure that details like this is covered in the spec and not "just being there for people to find out" in the conformance checker or the HTML5libraries cannot be a bad thing.

[zcorpan]

Yep.
That, and some additional information about how the <!-- commenting practice by nescessity must be handled differently by authors using XHTML5

Hm. The "Writing HTML documents" section doesn't apply to XHTML5 at all... so I'm not sure what it should say. Just reiterate in the note (if it's added) that "This does not apply to XHTML" or something?

One reasons I took this up in the first place was that I (very briefly) assumed that since the <!-- issue wasn't handled (or even mentioned) in the WA1-spec it was gone.

Ok. Makes sense since it isn't handled by HTML -- it's handled by CSS and JS (the latter still being de facto).

Again - the spec is where some of us go to find out how things are supposed to work. IMHO making sure that details like this is covered in the spec and not "just being there for people to find out" in the conformance checker or the HTML5libraries cannot be a bad thing.

Agreed.

[Jarvklo]

Hm. The "Writing HTML documents" section doesn't apply to XHTML5 at all... so I'm not sure what it should say. Just reiterate in the note (if it's added) that "This does not apply to XHTML" or something?

Well... Not quite IMHO.
The currently expected behaviour is made explicit both in the XHTML 1.0 recommendation - http://www.w3.org/TR/xhtml1/#h-4.8 - and in the HTML4.01 rec (as referenced earlier in this thread)

XML parsing is, for example, mentioned as a reason to exclude the use of <noscript> from XHTML5 documents... and since XML parsers aren't *required* to include comments in the resulting tree structures it is not quite clear from the current text IMHO how WA1 in an XHTML serialization handles this by design...

I think a description of *what* actually applies to both an HTML5 and an XHTML5 serialization of a document containing a

Code: Select all

<script type="text/javascript"><!-- //HTML style comment enclosing code in a script element --></script>

or a

Code: Select all

<script type="text/javascript"><![CDATA[ block of code enclosed in an explicit CDATA section //]]></script>

needs to be in the spec in some form if you agree with my reasoning in this thread about details and differences needing to be clear in the spec itself

[zcorpan]

Hmm. So you effectively want http://wiki.whatwg.org/wiki/HtmlVsXhtml to be included as a non-normative appendix to the spec? Or referenced to by the spec (e.g. in the HTML vs. XHTML section)?

[zcorpan]

XML parsing is, for example, mentioned as a reason to exclude the use of <noscript> from XHTML5 documents... and since XML parsers aren't *required* to include comments in the resulting tree structures it is not quite clear from the current text IMHO how WA1 in an XHTML serialization handles this by design...

FWIW, even if they do include the comments (like most browsers do), they will still be comments in the DOM (as opposed to text nodes), so they still are not passed on to the CSS parser or JS engine.

If the script is inline, then, for scripting languages that consist of pure text, user agents must use the value of the DOM text attribute (defined below) as the script to execute, and for XML-based scripting languages, user agents must use all the child nodes of the script element as the script to execute.

-- http://www.whatwg.org/specs/web-apps/cu ... #executing

All descendant elements must be processed, according to their semantics, before the style element itself is evaluated. For styling languages that consist of pure text, user agents must evaluate style elements by passing the concatenation of the contents of all the text nodes that are direct children of the style element (not any other nodes such as comments or elements), in tree order, to the style system. For XML-based styling languages, user agents must pass all the children nodes of the style element to the style system.

-- http://www.whatwg.org/specs/web-apps/cu ... #the-style

<noscript> isn't allowed in XHTML5 because it doesn't work in XHTML. In HTML it is parsed differently depending on whether scripting is enabled or not. That cannot be done with an XML parser. It's main use-case is also in combination with document.write() scripts, which also don't work in XML (it could perhaps be made to work, but it's unclear how), so it isn't really needed anyway.

[Jarvklo]

Hmm. So you effectively want http://wiki.whatwg.org/wiki/HtmlVsXhtml to be included as a non-normative appendix to the spec? Or referenced to by the spec (e.g. in the HTML vs. XHTML section)?

I don't know nor care how this is best done. Do as you wish.
All I'm saying is that IMHO this is currently not made clear (in fact, is missing) from the spec and humbly suggest that this is a problem. If it's outside the scope of the spec then so be it

I think I've got as good an answer as anyone might expect at this point.

[Jarvklo]

<noscript> isn't allowed in XHTML5 because it doesn't work in XHTML. In HTML it is parsed differently depending on whether scripting is enabled or not.

Well - this is IMHO unfortunate at best. It sort of makes it impossible to handle all aspects of eg. http://www.w3.org/TR/WCAG/#tech-scripts in XHTML5.

That cannot be done with an XML parser. It's main use-case is also in combination with document.write() scripts, which also don't work in XML (it could perhaps be made to work, but it's unclear how), so it isn't really needed anyway.

Eh, - Now I'm even more confused. I wouldnt *dream* of placing a document.write based script inside of a <noscript> even in HTML4 !
But maybe I misunderstand what you mean. Perhaps if you could point me to that use case ?

[edit:] BTW when you say that <noscript> doesn't work in XHTML you surely must mean XHTML5? Seems to me it works just fine in XHTML 1.0 Strict served as application/xhtml+xml to at least some very common browsers like FireFox/Win and Opera/Win (you can try it out at the frontpage of http://xhtml.se if your browser indicates it prefers application/xhtml+xml over text/html)- or maybe I'm missing something obvious ? (in which case I'd be very geratful for some insightful references)