Re: Mutation events replacement

On Wed, Jul 20, 2011 at 11:56 AM, Aryeh Gregor <Simetrical+w3c@gmail.com>wrote:

> On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan <dflanagan@mozilla.com>
> wrote:
> > Finally, I still think it is worth thinking about trying to model the
> > distinction between removing nodes from the document tree and moving them
> > (atomically) within the tree.
>
> I'll chip in that I think this is useful.  It makes things somewhat
> more complicated, but remove/insert and move are conceptually very
> different.
>

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?

e.g. say we have <div>hello<br>world<br>w3c<br></div>

And we have a hypothetical function that does:


   1. Remove all children of div
      2. Inserts "w3c" back after div.

Then what should the list of mutations contain?  Should it contain 2 items
one that says it removed "hello", "world", and 3 br's, and then another one
saying "w3c" moved?  But then child nodes are not all consecutive and
scripts won't be able to infer where these nodes were even if we provided
offsets or before/after node.

Should it contain 3 items, one that says "hello", "world" and the first 2
br's are removed, then one for moving "w3c", and then another one for
removing the last br?  But then UAs have to keep reorganizing the list as
the function modifies more DOM because there is no way to differentiate
"w3c" until it's inserted back into DOM.


- Ryosuke