13153 2011-07-05 20:40:13 +0000 replaceData() should insert before deleting, to give better range mutation behavior 2011-07-14 14:44:44 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All All RESOLVED FIXED P2 enhancement --- 1 ayg annevk jonas mike www-dom public-webapps-bugzilla oldest_to_newest 50694 0 ayg 2011-07-05 20:40:13 +0000 Testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1062 This does replaceData(1, 1, "uu") on a text node "foo". A range collapsed like "fo[]o" then becomes "f[]uuo" per the current spec. This is because first you delete one character, so it becomes "f[]o", then you insert the new characters, and insertions always go after a boundary point. If you instead inserted them before the substring to be deleted, then deleted the substring, it would first be "fuuo[]o", then "fuu[]o". Then the boundary point goes where it logically belongs -- after the replacement for the thing it was already after. The current spec matches the behavior of IE9, Firefox 6.0a2, and Chrome 14 dev (they log "1" in the test). Opera 11.50 matches my proposed behavior (logs "3"). I don't think this would affect compat, so switching to Opera's behavior should be safe. To be clear, I'm asking that the spec be changed to say something like "The replaceData(offset, count, data) method must act as if the insertData() method is invoked with offset and data as arguments followed by the deleteData() method with (offset + data.length) and count as arguments and re-throw any exceptions these methods might have thrown." AFAIK, this should only affect range mutations (for the better) and mutation events (unlikely to make a compat difference, I hope). 50708 1 annevk 2011-07-06 08:23:04 +0000 We should also change to not describe this method in terms of other methods so when we land mutation listeners only one mutation is done for the whole operation. 50749 2 ayg 2011-07-06 20:32:02 +0000 If you do that, you can close this bug. DOM Range will need to special-case replaceData() then anyway. You reminded me to file bug 13164, though, which is a better way of handling integration with stuff like range mutations and mutation events IMO. 51005 3 annevk 2011-07-14 11:44:27 +0000 Can you look at the current text to see whether it is okay? 51019 4 ayg 2011-07-14 14:44:44 +0000 Looks good to me, thanks!