Re: Mutation events replacement

On Fri, Jul 1, 2011 at 5:36 PM, Rafael Weinstein <rafaelw@google.com> wrote:

> We've been prototyping more useful higher-level semantics on top of
> what we've proposed (akin to what you're asking about). In general, if
> you want to know something correct about what happened to a tree from
> state (a) to state (b) you need to register an observer at all nodes
> in the tree for the types of changes you care about. Subtree
> observation isn't sufficient for this purpose exactly for the reason
> you are observing: you don't hear about when something that was in
> tree was removed, modified, then returned.
>

Why?  If I have a list of mutations that happened in a subtree with
information such as containerNode, offset at which the node was inserted or
removed, shouldn't I be able to tell exactly what had happened?

We've prototyped the semantics of our proposal and are working on
> implementing higher-level observation semantics on top of them. It's
> still work in progress, but you can get an idea of what's required.
>

I'll add that being able to annotate a sequence of mutations with
higher-level semantics will be super useful.  For example, if execCommand or
editing actions make a bunch of modifications, they should all be grouped
together and and label as such.  Also, a widget library can label all
mutations caused by the creation of a widget to avoid shooting itself or
inform other components and libraries on the page.

- Ryosuke