This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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?
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].
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.
This should be no problem for Opera. What do other implementors think?
(Remember to credit Daniel Bratell for information on Opera if we decide to do this.)
So selecting parts of PI data using range would become possible?
As stated in comment 2 you already can.
No. Comment 2 says you can put PI as container, but it does not test if one can select part of the data.
Created attachment 964 [details] a testcase
But still, I think this change does make sense.
I assume selecting comment node's data should become supported too?
(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."
Created attachment 966 [details] 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.
Seems like deleteContents would just work on Gecko if PI was CharacterData. ToString() would need still some work.
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?
(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.
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.
I still think it makes sense to pursue this though.
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.
Yeah, not much is solved by this.
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.
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.
Lets do this. https://bitbucket.org/ms2ger/dom-core/changeset/ec64d3d1852d