12841 2011-06-01 07:44:57 +0000 Add CDATASection 2011-09-19 08:07:03 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All All RESOLVED WONTFIX P2 normal --- 1 Ms2ger annevk ayg daniel.glazman glenn jonas kennyluck mike www-dom public-webapps-bugzilla oldest_to_newest 48996 0 Ms2ger 2011-06-01 07:44:57 +0000 49031 1 ayg 2011-06-01 20:00:13 +0000 Blech, why? Are implementers not willing to drop support? This will require a lot of review of specs that depend on DOM Core, including DOM Range and HTML Editing Commands. Plus it's yet another DOM feature that only happens in XML, right? 49035 2 jonas 2011-06-01 21:20:20 +0000 Yes, I'd like to see some solid reasons why in order for us to include CDATA sections. Note that "It was in DOM Level 3" is IMO a completely invalid reason. If the feature can't stand on it's own, it's not worth keeping. 49068 3 ayg 2011-06-02 18:06:16 +0000 Well, it's not just that it's in DOM 3 Core, it's also interoperably implemented: data:application/xhtml+xml, <html xmlns="http://www.w3.org/1999/xhtml"> <body><![CDATA[abc]]> <script>alert(document.body.firstChild);</script> </body></html> That alerts "[object CDATASection]" in Gecko, WebKit, and Presto. (I assume IE9 too, but didn't bother testing because it doesn't support data URLs in the URL bar.) So the question is whether everyone is willing to drop support. 49069 4 jonas 2011-06-02 18:25:27 +0000 Sure. Let me revise that. IMO "Previous DOM specs support it and so does implementations" is not a valid argument. If a feature isn't good and useful it should be removed no matter how much it's implemented. If it's widely *used* though, that is a different argument which would carry a lot more. And yes, I'm absolutely willing to remove it from Gecko. 49200 5 daniel.glazman 2011-06-05 16:37:49 +0000 I strongly disagree. |document.createCDATASection| has been available in the DOM apis since 1996. Removing it just to remove it makes no sense at all and you just have no idea, no stats, no metrics whatsoever to show and prove that this is unused not only in web pages but also in all DOM-based tools or applications, on the web or in batch systems. For what it's worth, BlueGriffon uses and needs it. I am not against making **internally** CDATASection look and feel like Text nodes (using a boolean flag) **as soon as** parsing, serialization and APIs related to CDATASections remain unchanged, untouched and backwards-compatible with all existing use cases. 49207 6 ayg 2011-06-05 19:54:01 +0000 What does BlueGriffon use CDATASection for? The current spec just implies that nodes in the DOM can't be CDATASection. Presumably a CDATA section in XML input would become a Text node when it's parsed, instead of a CDATASection node. It would still work pretty much the same in practice, although presumably it would be serialized differently. What would break in BlueGriffon here? CDATASection is evil for the web because it only occurs in XML, which means it's a weird corner case. We know it's not used on the web to any appreciable extent because it's XHTML-only, and XHTML is not used on the web to any appreciable extent. Non-web users of DOM aren't obligated to implement the new DOM Core, which is designed primarily to be web-compatible. 49788 7 annevk 2011-06-17 16:18:11 +0000 To reopen please answer comment 1. 56975 8 annevk 2011-09-19 08:07:03 +0000 *** Bug 14205 has been marked as a duplicate of this bug. ***