13604 2011-08-03 12:52:36 +0000 CDATA sections are no allowed except in foreign content 2013-11-02 11:12:45 +0000 1 1 1 Unclassified HTML WG LC1 HTML/XHTML Compatibility Authoring Guide (ed: Eliot Graff) unspecified PC Linux RESOLVED FIXED http://dev.w3.org/html5/html-polyglot/html-polyglot.html#named-entity-references P2 normal --- 23593 1 plh xn--mlform-iua davidc eliotgra hsivonen mike public-html-admin public-html-wg-issue-tracking xn--mlform-iua public-html-bugzilla oldest_to_newest 52156 0 plh 2011-08-03 12:52:36 +0000 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 52232 1 davidc 2011-08-03 20:20:24 +0000 (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 52238 2 plh 2011-08-03 20:34:35 +0000 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. 52245 3 davidc 2011-08-03 20:43:52 +0000 (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 52255 4 plh 2011-08-03 21:17:27 +0000 (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. 53180 5 mike 2011-08-04 05:07:22 +0000 mass-move component to LC1 53210 6 mike 2011-08-04 05:07:41 +0000 mass-move component to LC1 54156 7 hsivonen 2011-08-04 07:47:30 +0000 (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 54232 8 hsivonen 2011-08-05 13:26:24 +0000 For clarity, my comment was about text in SVG or MathML parents. Polyglot docs clearly can't use CDATA sections with HTML parents. 54233 9 hsivonen 2011-08-05 13:27:55 +0000 In fact, comment 7 is irrelevant on this bug report. 95597 10 xn--mlform-iua 2013-10-31 00:36:44 +0000 (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. 95729 11 xn--mlform-iua 2013-11-02 11:12:11 +0000 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. 95730 12 xn--mlform-iua 2013-11-02 11:12:45 +0000 (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