Re: Mutation events replacement

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