This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
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.
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.
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.
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.
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.
To reopen please answer comment 1.
*** Bug 14205 has been marked as a duplicate of this bug. ***