Re: Mutation events replacement

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.  I'd really want to handle them differently for range
mutations, as I previously explained:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/031053.html

A move operation is unnecessary if the goal is to synchronize changes
between DOMs, but it's useful if the goal is to store and update data
about the nodes themselves.  In that case, moving a node could imply a
very different sort of change to the data than removing/inserting.
Specifically, you might want to throw away data when a node is
removed, but keep it when the node is moved.  Like:

* If some nodes get moved to a nearby position and are in a Range to
start with, they might conceptually belong in the Range afterward.
See the examples in the e-mail I link to before.  If they're removed
and re-inserted, you have to keep extra state somewhere to track that.
 In my edit commands spec, I had to work around this in many different
places by defining special primitives like "move preserving ranges",
or in some cases by manually saying "For every Range with boundary
point X, do Y".
* If you're associating spellcheck data with text nodes in an editable
region, then if a node gets moved elsewhere within the region, you
want to keep the data.  If it gets removed, you want to throw away the
data.
* Other things?

Of course, we'd have to update every method anywhere that moves nodes
to do so atomically instead of removing then inserting.

Do we have a list of use-cases for mutation events anywhere?

Received on Wednesday, 20 July 2011 18:57:42 UTC