This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
https://dom.spec.whatwg.org/#dom-document-createcdatasection See usage: https://www.chromestatus.com/metrics/feature/timeline/popularity/113 This is around 0.01%, and being a function it hurts more to remove than attributes and interfaces. Some Node-related removals failed despite lower usage. Options: 1. Bring back CDATASection in all its glory. 2. Have createCDATASection() return a Text node.
I doubt anyone would be surprised that I prefer (2).
Philip, I think first attempting to change the result of the following demo and then deciding what we should do here is a better order: data:text/xml,<script xmlns="http://www.w3.org/1999/xhtml"><![CDATA[alert(document.currentScript.firstChild.nodeType)]]></script>
If we do (2), the Text node should probably have the .serializeAsCDATA attribute set. It seems that attribute is no longer defined in DOMParsing.
There's code that relies on serialization? Can't we first figure out if just making the XML parser output Text nodes breaks anything?
Where we can find earlier version of Parsing & Serialization spec made by WHATWG? Old link automatically moves to W3C editor's draft: http://domparsing.spec.whatwg.org/ where proposal of Text.serializeAsCDATA attribute not exist.
https://rawgit.com/whatwg/domparsing/edc795ccfdc03e396197bf81a0f550105930e90b/source.html or https://github.com/whatwg/domparsing but it is no longer maintained.
AFAICT, these are the ways that CDATASection is observable in Blink: 1. The CDATASection interface itself 2. CDATASection.nodeName is "#cdata-section" 3. CDATASection.nodeType is 4 (CDATA_SECTION_NODE) 4. Document.createCDATASection() 5. The XML parser can create CDATASection 6. XMLSerializer.serializeToString() can serialize CDATASection I could add counters for 2, 3, 5 and 6 (1 is hard to count and 4 already counted) but even if the usage is high it could still be safe to remove if people are just iterating over documents and dispatching based on nodeType, for example. Would counters for the above or anything else be worthwhile adding? Is there a spec for XML parsing that we should have changed if we try changing the parser to output Text nodes instead of CDATASection?
The XML specification does not define what nodes to create. My idea was always that https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html in combination with HTML's "XML parser" definition would define that.
I think if we can change the XML parser, we have a good shot at changing the rest.
What should happen in the case where the XML parser would previously output a CDATASection with a preceding or following Text node? It seems odd to have sibling Text nodes, but collapsing them would be more work.
I think ideally it would be one node, but not having CDATASection nodes would be a good start.
OK, it looks like creating a single text nodes was easier than I thought. Simon was kind enough to grep some real data for createCDATASection: http://krijnhoetmer.nl/irc-logs/whatwg/20141127#l-355 It's all "targetNode.appendChild(document.createCDATASection(elementsObject[key]));" which would work if createCDATASection() returns a Text node, so that's promising.
Several interesting questions around removal CDATA was raised in: https://bugzilla.mozilla.org/show_bug.cgi?id=660660 https://www.w3.org/Bugs/Public/show_bug.cgi?id=12841
I experimented with the parser change today, and the resulting test failures were illuminating. First, any code that looks for a CDATASection (nodeType 4) is obviously going to break. A more problematic case is innerHTML. Before, innerHTML would return something very similar to the source, including the "<![CDATA[" and "]]>". After the change, those were of course gone, and any "<" characters in the source will be serialized as "<" instead. There was one test case which accidentally depended on this. This makes me a bit worried. Counting instance where a CDATASection node is serialized could be useful, but finding the cases where there's an actual problem is very, very hard without actually making the change.
Mozilla devs, what are your thoughts on the parser change? It seems like quite the gamble without further data, but I don't know how to investigate the compat risk.
Another case where serialization differences are observable is with XMLHttpRequest.send(document).
Data for application/xhtml+xml + <![CDATA[ https://gist.github.com/anonymous/bf63359fc7d45f16effc
(In reply to Simon Pieters from comment #17) > Data for application/xhtml+xml + <![CDATA[ > > https://gist.github.com/anonymous/bf63359fc7d45f16effc Since all of these are coupled with // or /**/ comments it seems likely that they're just for <script> or <style> without relying on the type of node produced.
Philip indicated he's not excited about putting effort into removing this node. Ms2ger said he didn't want to add it to Servo. I guess if this is still unchanged when I'm 30, we'll call it a day and add it back in.
(In reply to Anne from comment #19) > Philip indicated he's not excited about putting effort into removing this > node. Ms2ger said he didn't want to add it to Servo. I guess if this is > still unchanged when I'm 30, we'll call it a day and add it back in. I'm reliably informed that's in almost exactly a year.
https://github.com/whatwg/dom/pull/295