Bug 15297 - Range.insertNode()
Summary: Range.insertNode()
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-21 09:34 UTC by Anne
Modified: 2011-12-28 19:59 UTC (History)
12 users (show)

See Also:


Attachments
testcase (405 bytes, text/html)
2011-12-22 18:56 UTC, Olli Pettay
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anne 2011-12-21 09:34:53 UTC
This is currently an open issue in the DOM standard: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-range-insertnode

Aryeh's tests are testing for the Gecko behavior.

WebKit's bug is here https://bugs.webkit.org/show_bug.cgi?id=16867

Opera is leaning towards aligning with Gecko.

Feedback appreciated, especially from Microsoft.
Comment 1 Ojan Vafai 2011-12-22 18:45:48 UTC
I don't really understand the note in the spec and the webkit bug seems generic for all insertNode related issues. Can you give an example or two where the behavior differs?
Comment 2 Olli Pettay 2011-12-22 18:56:01 UTC
Created attachment 1054 [details]
testcase

Gecko selects nothing new, webkit selects the newly added text node
Comment 3 Jacob Rossi [MSFT] 2011-12-27 18:34:03 UTC
We're aware that we differ from the spec. We implemented it this way to be interoperable with the majority of other browsers. Additionally, I think our behavior makes more sense for web devs than what the spec describes. I would expect that calling insertNode would imply that you move the end point to include the inserted node--in other words, the node is included in the selection.

If instead you first started with <div><span></span></div>  and selected the contents of the div, then the offsets would be 0,1. Then, if you inserted another span using insertNode, it would be 0,2. 

I see no compelling reason why it should behave differently when collapsed--but we'd be willing to entertain a change here if there's consensus that the spec'd behavior is better for web developers.
Comment 4 Anne 2011-12-27 19:08:53 UTC
Personally I'm with you Jacob. I never quite understood why Olli thought the other behavior was better. I just don't care strongly either way :-)
Comment 5 Olli Pettay 2011-12-27 19:14:02 UTC
I prefer consistency.
DOM 2 Range handled insertNode like normal DOM mutation.
DOM 4 requires some special handling.
Comment 6 Anne 2011-12-27 19:16:31 UTC
But don't you expect the special handling given that you insert a node into a Range (collapsed or not)? That's the name of the method after all.
Comment 7 Jacob Rossi [MSFT] 2011-12-27 19:18:38 UTC
For what it's worth, I don't feel strongly about one or the other either. If all major browsers but one are interoperable, then I would think we'd want a good reason why the currently spec'd design is better for web developers in order to keep it. But if there's enough consensus that the spec'd behavior is better, then I think we're open to considering a change. All in all, this is pretty minor.

Consistency is a good argument for web developers. Though, I feel that IE/Webkit/Opera's behavior is more predictable/consistent with my expectations--insertNode on a Range always selects the inserted node. Having it behave differently for the collapsed case actually seems more of an inconsistency to me (and in fact, would actually have to be a special case in our implementation if we changed it).
Comment 8 Aryeh Gregor 2011-12-27 20:30:09 UTC
I'm for changing to match IE/WebKit/Opera.  Their behavior makes at least as much sense as DOM 2 Range/Gecko, and moving to match it requires fewer UAs to change.
Comment 9 Olli Pettay 2011-12-28 10:48:50 UTC
(In reply to comment #6)
> But don't you expect the special handling given that you insert a node into a
> Range (collapsed or not)? That's the name of the method after all.

Not sure. It depends on how one interprets "insertNode". Whether it is 
insert a node into a Range, or insert node to the place the Range indicates. 
DOM 2 Range nicely allows both interpretations:
"A node may be inserted into a Range"
"The node is inserted at the start boundary-point of the Range, without modifying it."
Comment 10 Olli Pettay 2011-12-28 10:50:10 UTC
DOM4 doesn't seem to say what the method is supposed to do,
it has just the pseudo-code.
Comment 11 Anne 2011-12-28 10:51:52 UTC
We can add the non-normative descriptions once we decide on behavior.
Comment 12 Aryeh Gregor 2011-12-28 19:59:14 UTC
Changed, as agreed with annevk on IRC:

http://dvcs.w3.org/hg/domcore/rev/c6ad35d540ae
http://dvcs.w3.org/hg/webapps/rev/0e0ccea27522

Sorry that this punishes Gecko for following (what used to be) the spec, but that's not as strong a consideration as matching the majority of browsers.  The spec now gets the offsets exactly the same as WebKit in all of my tests, differing from IE only in corner cases (I think -- couldn't check myself right now).