This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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?
Created attachment 1054 [details] testcase Gecko selects nothing new, webkit selects the newly added text node
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.
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 :-)
I prefer consistency. DOM 2 Range handled insertNode like normal DOM mutation. DOM 4 requires some special handling.
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.
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).
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.
(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."
DOM4 doesn't seem to say what the method is supposed to do, it has just the pseudo-code.
We can add the non-normative descriptions once we decide on behavior.
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).