15297 2011-12-21 09:34:53 +0000 Range.insertNode() 2011-12-28 19:59:14 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC All RESOLVED FIXED P2 normal --- 1 annevk annevk adrianba ap ayg bugs ian jonas jrossi mike mjs ojan travil www-dom public-webapps-bugzilla oldest_to_newest 61869 0 annevk 2011-12-21 09:34:53 +0000 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. 61949 1 ojan 2011-12-22 18:45:48 +0000 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? 61950 2 1054 bugs 2011-12-22 18:56:01 +0000 Created attachment 1054 testcase Gecko selects nothing new, webkit selects the newly added text node 62049 3 jrossi 2011-12-27 18:34:03 +0000 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. 62051 4 annevk 2011-12-27 19:08:53 +0000 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 :-) 62052 5 bugs 2011-12-27 19:14:02 +0000 I prefer consistency. DOM 2 Range handled insertNode like normal DOM mutation. DOM 4 requires some special handling. 62053 6 annevk 2011-12-27 19:16:31 +0000 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. 62054 7 jrossi 2011-12-27 19:18:38 +0000 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). 62061 8 ayg 2011-12-27 20:30:09 +0000 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. 62093 9 bugs 2011-12-28 10:48:50 +0000 (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." 62094 10 bugs 2011-12-28 10:50:10 +0000 DOM4 doesn't seem to say what the method is supposed to do, it has just the pseudo-code. 62095 11 annevk 2011-12-28 10:51:52 +0000 We can add the non-normative descriptions once we decide on behavior. 62113 12 ayg 2011-12-28 19:59:14 +0000 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). 1054 2011-12-22 18:56:01 +0000 2011-12-22 18:56:01 +0000 testcase insertnode.html text/html 405 bugs PCFET0NUWVBFIGh0bWw+CjxodG1sPgogIDxoZWFkPgogICAgPHNjcmlwdD4KICAgIGZ1bmN0aW9u IHRlc3QoKSB7CiAgICAgIGRvY3VtZW50LmJvZHkuaW5uZXJIVE1MID0gIiI7CiAgICAgIHZhciBy ID0gZG9jdW1lbnQuY3JlYXRlUmFuZ2UoKTsKICAgICAgci5zZWxlY3ROb2RlQ29udGVudHMoZG9j dW1lbnQuYm9keSk7CiAgICAgIHIuaW5zZXJ0Tm9kZShkb2N1bWVudC5jcmVhdGVUZXh0Tm9kZSgi Zm9vIikpOwogICAgICBhbGVydCgiUmFuZ2UgYWZ0ZXIgaW5zZXJ0aW5nICdmb28nIHVzaW5nIHth IGNvbGxhcHNlZCByYW5nZX0uaW5zZXJ0Tm9kZSgpOiBbIiArIHIgKyAiXSIpOwogICAgfQogICAg PC9zY3JpcHQ+CiAgPC9oZWFkPgogIDxib2R5IG9ubG9hZD0idGVzdCgpIj4KICA8L2JvZHk+Cjwv aHRtbD4K