12205 2011-02-28 20:20:04 +0000 Make ProcessingInstruction implement CharacterData 2011-09-01 09:54:42 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All All RESOLVED FIXED P2 enhancement --- 1 ayg annevk adrianba ap bugs bzbarsky jonas mike mjs ojan tross www-dom public-webapps-bugzilla oldest_to_newest 46101 0 ayg 2011-02-28 20:20:04 +0000 All DOM specs have to deal with ProcessingInstructions for completeness, and it would be simpler if we could just deal with them at the same time as Comments and Text nodes instead of special-casing them. Currently we often can't, because their "data" attribute isn't actually the same as CharacterData's and they don't have all the handy features. Example where PIs need to be special-cased: http://html5.org/specs/dom-range.html#concept-node-length It's also coming up when I'm speccing Range.deleteContents(). Browsers don't make PIs implement CharacterData right now, but I can't imagine it would be more than a few lines' change; and since no one uses XML, I find it hard to believe there'd be any compat problem. 46103 1 bzbarsky 2011-02-28 20:54:12 +0000 This would be more than a few line's change. In particular, right now you can't position a Range inside a PI, right? Would you be able to if it were a CharacterData? 46117 2 ayg 2011-02-28 23:56:09 +0000 Per the DOM Range spec, you can position a Range inside a PI right now. The only thing you can't put it in is a DocumentType. Test-case: data:application/xhtml+xml, <html xmlns="http://www.w3.org/1999/xhtml"><head><script> var pi = document.createProcessingInstruction("a", "abc"); var range = document.createRange(); range.selectNodeContents(pi); alert(range.startContainer); </script></head></html> Opera 11 throws a BAD_BOUNDARYPOINTS_ERR, but Firefox 4b11 and Chrome 11 dev both alert [object ProcessingInstruction]. 46124 3 bzbarsky 2011-03-01 01:54:13 +0000 Ah, I see. Hmm. It looks like we may in fact share the same code as Text and CDATA nodes for ProcessingInstruction in Gecko, ok. 46318 4 annevk 2011-03-04 13:13:02 +0000 This should be no problem for Opera. What do other implementors think? 46320 5 annevk 2011-03-04 13:43:41 +0000 (Remember to credit Daniel Bratell for information on Opera if we decide to do this.) 46321 6 bugs 2011-03-04 13:52:09 +0000 So selecting parts of PI data using range would become possible? 46322 7 annevk 2011-03-04 13:54:42 +0000 As stated in comment 2 you already can. 46323 8 bugs 2011-03-04 14:01:26 +0000 No. Comment 2 says you can put PI as container, but it does not test if one can select part of the data. 46324 9 964 bugs 2011-03-04 14:06:23 +0000 Created attachment 964 a testcase 46325 10 bugs 2011-03-04 14:09:07 +0000 But still, I think this change does make sense. 46326 11 bugs 2011-03-04 14:41:38 +0000 I assume selecting comment node's data should become supported too? 46327 12 bugs 2011-03-04 14:53:00 +0000 (In reply to comment #9) > Created attachment 964 [details] > a testcase Ah, actually, this just shows similar bug in Gecko and Webkit since "If the container is a CharacterData, Comment or ProcessingInstruction node, the offset is between the 16-bit units of the UTF-16 encoded string contained by it." 46340 13 966 ap 2011-03-04 17:14:59 +0000 Created attachment 966 selecting PI content You can select PI data in WebKit, it's just toString() only collecting data from TEXT_NODE and CDATA_SECTION_NODE nodes. As far as I can tell, the same is true for Gecko, and it appears to be quite reasonable behavior. Furthermore, Range.deleteContents works with PIs in WebKit, but not in Gecko (tested with Firefox 3.6). I'm not sure if adding CharacterData methods like appendData() or insertData() to PI makes a lot of sense. 46341 14 bugs 2011-03-04 17:20:32 +0000 Seems like deleteContents would just work on Gecko if PI was CharacterData. ToString() would need still some work. 46342 15 adrianba 2011-03-04 17:24:30 +0000 Seems like IE's current behaviour is currently closest to what Opera does. This seems like an edge-case, though, so without a strong use case it probably wouldn't be a high priority for us to spend time on. Is there a reason why this is important to change? 46347 16 ayg 2011-03-04 17:48:45 +0000 (In reply to comment #13) > You can select PI data in WebKit, it's just toString() only collecting data > from TEXT_NODE and CDATA_SECTION_NODE nodes. As far as I can tell, the same is > true for Gecko, and it appears to be quite reasonable behavior. Yes, this is what the spec requires. toString() on a Range is basically like textContent, it only hits text nodes. > Furthermore, Range.deleteContents works with PIs in WebKit, but not in Gecko > (tested with Firefox 3.6). Yep, I was just writing some tests for deleteContents() and I noticed that (the processingInstruction test): http://aryeh.name/spec/dom-range/test/Range-deleteContents.html (In reply to comment #15) > Seems like IE's current behaviour is currently closest to what Opera does. This > seems like an edge-case, though, so without a strong use case it probably > wouldn't be a high priority for us to spend time on. Is there a reason why this > is important to change? No, it would just make the specs a bit simpler, allowing us to avoid some edge-cases in general in the specs (and I imagine in code too). There's no reason implementers need to be in any hurry to actually change their implementations anytime soon, as long as they aren't averse to changing them in principle. 47140 17 ayg 2011-04-04 20:14:50 +0000 Okay, after consultation with Ms2ger, I'm going to solve this by just prohibiting ProcessingInstructions from being Range endpoints, like DocumentTypes. IE and Opera already do this, and it will be easier for Gecko/WebKit to implement than the alternative. I'm fine if this bug is closed WONTFIX. 49857 18 annevk 2011-06-19 15:49:53 +0000 I still think it makes sense to pursue this though. 49862 19 jonas 2011-06-19 21:48:11 +0000 I'd be ok with adding CharacterData to PIs. However I also don't see any big benefits in doing so. We still have to deal with non-characterdata elements appearing in the tree in the form of doctypes. 51492 20 annevk 2011-07-26 16:51:20 +0000 Yeah, not much is solved by this. 51980 21 annevk 2011-08-02 10:16:05 +0000 Actually, I want to reconsider. The difference with doctypes is that doctypes are not mutable. ProcessingInstruction.data is mutable in the exact same way Text.data and Comment.data are mutable. As such it makes a lot of sense to group them together. If we do not want to expose the methods of CharacterData on ProcessingInstruction we could put another interface between CharacterData and Text/Comment that has them or put them on Text/Comment directly. 56109 22 bugs 2011-08-31 14:01:16 +0000 This simplifies range handling, we should just do this. I would implement this (or accept patches ;)) for Gecko. Nowhere near top priority thing of course. 56164 23 annevk 2011-09-01 09:54:42 +0000 Lets do this. https://bitbucket.org/ms2ger/dom-core/changeset/ec64d3d1852d 964 2011-03-04 14:06:23 +0000 2011-03-04 14:06:23 +0000 a testcase rangepi.xhtml application/xhtml+xml 470 bugs PD94bWwgdmVyc2lvbj0iMS4wIj8+CjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5 L3hodG1sIj48aGVhZD48c2NyaXB0Pgp2YXIgcyA9ICJmb29QQVNTZm9vIjsKdmFyIHBpID0gZG9j dW1lbnQuY3JlYXRlUHJvY2Vzc2luZ0luc3RydWN0aW9uKCJhIiwgcyk7CnZhciByMSA9IGRvY3Vt ZW50LmNyZWF0ZVJhbmdlKCk7CnIxLnNldFN0YXJ0KHBpLCAzKTsKcjEuc2V0RW5kKHBpLCA3KTsK YWxlcnQoIkRhdGEgc2VsZWN0aW9uIHVzaW5nIFBJOiAiICsgcjEudG9TdHJpbmcoKSk7Cgp2YXIg dCA9IGRvY3VtZW50LmNyZWF0ZVRleHROb2RlKHMpOwp2YXIgcjIgPSBkb2N1bWVudC5jcmVhdGVS YW5nZSgpOwpyMi5zZXRTdGFydCh0LCAzKTsKcjIuc2V0RW5kKHQsIDcpOwphbGVydCgiRGF0YSBz ZWxlY3Rpb24gdXNpbmcgdGV4dCBub2RlOiAiICsgcjIudG9TdHJpbmcoKSk7Cgo8L3NjcmlwdD48 L2hlYWQ+PC9odG1sPgo= 966 2011-03-04 17:14:59 +0000 2011-03-04 17:14:59 +0000 selecting PI content rangepi.xhtml application/xhtml+xml 388 ap PD94bWwgdmVyc2lvbj0iMS4wIj8+CjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5 L3hodG1sIj48aGVhZD48c2NyaXB0Pgp2YXIgcyA9ICJmb29QQVNTZm9vIjsKdmFyIHBpID0gZG9j dW1lbnQuY3JlYXRlUHJvY2Vzc2luZ0luc3RydWN0aW9uKCJhIiwgcyk7CnZhciByMSA9IGRvY3Vt ZW50LmNyZWF0ZVJhbmdlKCk7CnIxLnNldFN0YXJ0KHBpLCAzKTsKcjEuc2V0RW5kKHBpLCA3KTsK YWxlcnQocjEuc3RhcnRDb250YWluZXIgKyAiIC0gIiArIHIxLnN0YXJ0T2Zmc2V0ICsgIiwgIiAr IHIxLmVuZE9mZnNldCkKcjEuZGVsZXRlQ29udGVudHMoKTsKYWxlcnQoIkFmdGVyIGRlbGV0ZUNv bnRlbnRzOiAiICsgcGkuZGF0YSk7Cjwvc2NyaXB0PjwvaGVhZD48L2h0bWw+Cg==