- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Thu, 21 Jul 2011 16:15:22 -0400
- To: Ryosuke Niwa <rniwa@webkit.org>, Boris Zbarsky <bzbarsky@mit.edu>
- Cc: David Flanagan <dflanagan@mozilla.com>, public-webapps@w3.org
On Wed, Jul 20, 2011 at 3:11 PM, Ryosuke Niwa <rniwa@webkit.org> wrote: > But internally, a node movement is a removal then an insertion. There's > always possibility that a node gets removed then inserted again after > mutation observers are invoked. Also, what happens if a function removed a > bunch of nodes and then inserted back one of them? I'm suggesting that we change insertNode()/appendChild()/etc. so that they're *not* internally a removal then an insertion: they're internally atomic. If you call foo.removeChild(bar); foo.appendChild(bar) then that would be a remove/insert no matter what. But if you call foo.appendChild(bar) and bar has a parent and bar is not the last child of foo, that would be a move. Yes, this causes problems as long as mutation events exist. But when mutation event handlers modify the DOM, behavior is undefined and is totally inconsistent between browsers in practice, so I don't think it's a big deal. Just do whatever's convenient and leave the behavior inconsistent in this case like in others. We don't need to standardize behavior here unless we're going to standardize behavior in all other cases where DOM mutation listeners mutate the DOM, which we aren't. On Wed, Jul 20, 2011 at 10:17 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > What I do have a strong opinion on is that it would be good to have some > data on how common "move" operations are compared to "remove" and "insert" > on the web. Then we'll at least know how common or edge-case the situation > is and hence how much effort we should spend on optimizing for it... I can say that it's very common and critical for editors. Tons of what you're doing is shuffling nodes around: splitting up text nodes and wrapping bits of them in new elements that you just inserted before them, moving all the contents of an element next to it before you remove it, etc. Editors of various types seem like they're one of the big use-cases for a mutation events replacement anyway, so my guess is it's important. But nobody's even made a list of use-cases for mutation listeners, have they? I don't think moving nodes is as common a use-case for typical sites. But typical sites don't want mutation listeners either, so they aren't what we should be concerned about here.
Received on Thursday, 21 July 2011 20:16:10 UTC