Re: Mutation events replacement

On Thu, Jun 30, 2011 at 1:15 PM, David Flanagan <dflanagan@mozilla.com>wrote:
>
> avoid the need to maintain a list of pending callbacks.


Yeah, this is one reason I like Rafael's proposal of having a list of
mutations.  In many editing apps, you want to get a list of mutation events
for each editing action or execCommand call instead of receiving a mutation
event for each DOM mutation and having to pile them up.

a) The document tree just changed. The current state of the tree reflects
> the change and no other changes have occurred in the meantime. You can look,
> but you can't touch the tree.
>
> b) The document has changed, but the current state of the tree may include
> other, subsequent changes that I'm not going to tell you about yet.  Feel
> free to change the tree and mess things up even more for the next event
> handler in the queue.  :-)
>
> I think a is more useful, easier for web developers to understand, and less
> surprising.


Are there use cases where having just b or b + list of mutations is not
sufficient (i.e. being synchronous is necessary) ?

- Ryosuke