27386 2014-11-21 08:48:22 +0000 Removing createCDATASection() unlikely to be successful 2017-02-02 18:19:16 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All All RESOLVED MOVED https://www.w3.org/Bugs/Public/show_bug.cgi?id=30058 P2 normal --- 1 philipj annevk crimsteam mike Ms2ger VYV03354 www-dom zcorpan public-webapps-bugzilla oldest_to_newest 115271 0 philipj 2014-11-21 08:48:22 +0000 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. 115272 1 Ms2ger 2014-11-21 09:42:56 +0000 I doubt anyone would be surprised that I prefer (2). 115275 2 annevk 2014-11-21 10:31:46 +0000 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> 115278 3 zcorpan 2014-11-21 10:47:17 +0000 If we do (2), the Text node should probably have the .serializeAsCDATA attribute set. It seems that attribute is no longer defined in DOMParsing. 115279 4 annevk 2014-11-21 10:57:03 +0000 There's code that relies on serialization? Can't we first figure out if just making the XML parser output Text nodes breaks anything? 115293 5 crimsteam 2014-11-21 14:45:50 +0000 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. 115294 6 annevk 2014-11-21 14:50:27 +0000 https://rawgit.com/whatwg/domparsing/edc795ccfdc03e396197bf81a0f550105930e90b/source.html or https://github.com/whatwg/domparsing but it is no longer maintained. 115482 7 philipj 2014-11-25 22:45:41 +0000 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? 115494 8 annevk 2014-11-26 08:05:00 +0000 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. 115495 9 annevk 2014-11-26 08:05:30 +0000 I think if we can change the XML parser, we have a good shot at changing the rest. 115566 10 philipj 2014-11-26 22:16:42 +0000 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. 115595 11 annevk 2014-11-27 08:01:11 +0000 I think ideally it would be one node, but not having CDATASection nodes would be a good start. 115602 12 philipj 2014-11-27 09:29:38 +0000 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. 115627 13 crimsteam 2014-11-27 15:55:49 +0000 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 115633 14 philipj 2014-11-27 21:47:25 +0000 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 "&lt;" 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. 115652 15 philipj 2014-11-28 08:22:59 +0000 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. 115669 16 philipj 2014-11-28 14:13:49 +0000 Another case where serialization differences are observable is with XMLHttpRequest.send(document). 115729 17 zcorpan 2014-12-01 12:22:15 +0000 Data for application/xhtml+xml + <![CDATA[ https://gist.github.com/anonymous/bf63359fc7d45f16effc 115732 18 zcorpan 2014-12-01 13:15:48 +0000 (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. 122404 19 annevk 2015-08-03 13:27:06 +0000 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. 122406 20 philipj 2015-08-03 14:09:16 +0000 (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. 127139 21 annevk 2016-08-16 08:56:40 +0000 https://github.com/whatwg/dom/pull/295