(In reply to comment #0)
> The HTML5 spec is clear that "CDATA sections can only be used in foreign
> content (MathML or SVG)." [1].
> 
> However, the polyglot spec is mostly silent on those. Tidy generates CDATA
> sections for inline style and script when it outputs XHTML. It would be good to
> make it that those CDATA markers must not be used.
> 
> [1] http://www.w3.org/TR/html5/syntax.html#cdata-sections

the \\<![CDATA  markup doesn't generate a cdata section if used in an html script element (as < doesn't start markup in that context) so that usage doesn't contradict the fact that html doesn't allow cdata sections except in foreign content.

Like using linebreaks in svg attributes, this usage will cause difference between an htnl and xml DOM, but the difference is largely cosmetic, the difference just being whether the first line of the script that contains a jacascript comment has an empty comment (XML)  or a comment with the characters <!CDATA (from html parsing).

David

I believe you're correct, but it would nice to clarify section 9.2 In-line Script and Style then. At the moment, it says that polyglot must use safe content, it doesn't mention anything at all about CDATA sections.

(In reply to comment #2)
> I believe you're correct, but it would nice to clarify section 9.2 In-line
> Script and Style then. At the moment, it says that polyglot must use safe
> content, it doesn't mention anything at all about CDATA sections.

that's consistent with the aim as currently expressed that polyglot aims to get identical doms. For many purposes that is a more strict requirement than necessary.

there's nothing wrong with using the 
//<!CDATA[
idiom, but unless the polyglot spec weakens it's aims to "compatible" DOM for some definition of compatible then it is right to say that the script should not contain a < (so it can't contain <![CDATA, so there is no need to say anything further about CDATA sections.).

Specifying the requirements for identical dom is probably the right thing for the spec to do, the conditions under which non-identical doms are Ok are probably harder to specify in any generic way.

David

(In reply to comment #3)
> there's nothing wrong with using the 
> //<!CDATA[
> idiom, but unless the polyglot spec weakens it's aims to "compatible" DOM for
> some definition of compatible then it is right to say that the script should
> not contain a < (so it can't contain <![CDATA, so there is no need to say
> anything further about CDATA sections.).

Well, I still believe that being explicit would help the authors out there. There is nothing wrong with using CDATA in XHTML but, in Polyglot, those shouldn't be used since it won't produce identical doms.

mass-move component to LC1

mass-move component to LC1

(In reply to comment #4)
> Well, I still believe that being explicit would help the authors out there.
> There is nothing wrong with using CDATA in XHTML but, in Polyglot, those
> shouldn't be used since it won't produce identical doms.

If you desugar the DOMs, they are equivalent, though. The problem with talking about "the DOM" as a shorthand for the document tree is that the DOM has some domain modeling errors--particularly exposing the CDATA syntactic sugar in the data model.

Note that there's an ongoing attempt to remove this domain modeling error from the Web DOM: https://bugzilla.mozilla.org/show_bug.cgi?id=660660

For clarity, my comment was about text in SVG or MathML parents. Polyglot docs clearly can't use CDATA sections with HTML parents.

In fact, comment 7 is irrelevant on this bug report.

(In reply to Philippe Le Hegaret from comment #0)
> The HTML5 spec is clear that "CDATA sections can only be used in foreign
> content (MathML or SVG)." [1].
> 
> However, the polyglot spec is mostly silent on those. Tidy generates CDATA
> sections for inline style and script when it outputs XHTML. It would be good
> to make it that those CDATA markers must not be used.
> 
> [1] http://www.w3.org/TR/html5/syntax.html#cdata-sections

Since this bug was opened, some thing has happened: Polyglot Markup now has a section on raw text elements which, first, speaks about 'safe text' and thereafter, about 'safe CDATA': 

http://www.w3.org/TR/html-polyglot/#raw-text-elements

3.6.2 Raw text elements (script and style)
    3.6.2.1 The safe text content option
    3.6.2.2 The safe CDATA option

Thus it is possible that this bug is already fixed, in principle. However, bug 23593 might lead to some changes for the <script> element.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:


   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: Referred to polyglot’s rules for safe CDATA.
Rationale: Concurred withe bug filer.

Checked in:

http://dev.w3.org/cvsweb/html5/html-polyglot/html-polyglot.html?rev=1.14
http://dev.w3.org/cvsweb/html5/html-polyglot/html-polyglot.html?rev=1.14

Comment: As told, the spec now already defines safe CDATA. But I described some of the differences between CDATA in script/style vs CDATA in foreign content (including the link that Philip included in comment #0) in polyglot’s section on when to use (named) entities.

(In reply to Leif Halvard Silli from comment #11)

> Checked in:
> 
> http://dev.w3.org/cvsweb/html5/html-polyglot/html-polyglot.html?rev=1.14
> http://dev.w3.org/cvsweb/html5/html-polyglot/html-polyglot.html?rev=1.14

Meant:

http://dev.w3.org/cvsweb/html5/html-polyglot/html-polyglot.html?rev=1.13
http://dev.w3.org/cvsweb/html5/html-polyglot/html-polyglot.html?rev=1.14