This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12205 - Make ProcessingInstruction implement CharacterData
Summary: Make ProcessingInstruction implement CharacterData
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-28 20:20 UTC by Aryeh Gregor
Modified: 2011-09-01 09:54 UTC (History)
10 users (show)

See Also:


Attachments
a testcase (470 bytes, application/xhtml+xml)
2011-03-04 14:06 UTC, Olli Pettay
Details
selecting PI content (388 bytes, application/xhtml+xml)
2011-03-04 17:14 UTC, Alexey Proskuryakov
Details

Description Aryeh Gregor 2011-02-28 20:20:04 UTC
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.
Comment 1 Boris Zbarsky 2011-02-28 20:54:12 UTC
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?
Comment 2 Aryeh Gregor 2011-02-28 23:56:09 UTC
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].
Comment 3 Boris Zbarsky 2011-03-01 01:54:13 UTC
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.
Comment 4 Anne 2011-03-04 13:13:02 UTC
This should be no problem for Opera. What do other implementors think?
Comment 5 Anne 2011-03-04 13:43:41 UTC
(Remember to credit Daniel Bratell for information on Opera if we decide to do this.)
Comment 6 Olli Pettay 2011-03-04 13:52:09 UTC
So selecting parts of PI data using range would become possible?
Comment 7 Anne 2011-03-04 13:54:42 UTC
As stated in comment 2 you already can.
Comment 8 Olli Pettay 2011-03-04 14:01:26 UTC
No. Comment 2 says you can put PI as container, but it does not test
if one can select part of the data.
Comment 9 Olli Pettay 2011-03-04 14:06:23 UTC
Created attachment 964 [details]
a testcase
Comment 10 Olli Pettay 2011-03-04 14:09:07 UTC
But still, I think this change does make sense.
Comment 11 Olli Pettay 2011-03-04 14:41:38 UTC
I assume selecting comment node's data should become supported too?
Comment 12 Olli Pettay 2011-03-04 14:53:00 UTC
(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."
Comment 13 Alexey Proskuryakov 2011-03-04 17:14:59 UTC
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.
Comment 14 Olli Pettay 2011-03-04 17:20:32 UTC
Seems like deleteContents would just work on Gecko if
PI was CharacterData. ToString() would need still some work.
Comment 15 Adrian Bateman [MSFT] 2011-03-04 17:24:30 UTC
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?
Comment 16 Aryeh Gregor 2011-03-04 17:48:45 UTC
(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.
Comment 17 Aryeh Gregor 2011-04-04 20:14:50 UTC
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.
Comment 18 Anne 2011-06-19 15:49:53 UTC
I still think it makes sense to pursue this though.
Comment 19 Jonas Sicking (Not reading bugmail) 2011-06-19 21:48:11 UTC
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.
Comment 20 Anne 2011-07-26 16:51:20 UTC
Yeah, not much is solved by this.
Comment 21 Anne 2011-08-02 10:16:05 UTC
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.
Comment 22 Olli Pettay 2011-08-31 14:01:16 UTC
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.