Re: Mutation events replacement

On Thu, Jun 30, 2011 at 1:35 PM, Boris Zbarsky <> wrote:
>  The point of my proposal was to guarantee that mutation events are
>> delivered when the tree is in its freshly-mutated state and avoid the
>> need to maintain a list of pending callbacks.
> That would be nice; the problem is that there are compound mutation
> operations that can have "bad" intermediate states after part of the
> mutation has happened but before it's complete.  That's what the concern is
> about.

>   From a web developer's perspective what should a mutation event mean?
>> 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.
> What happens when the web page asks for layout information at this point?
>  Is it OK to force layout updates partway through a mutation?

I think most developers are concerned with paint to avoid flickering and not
so much about layout.

- Ryosuke

Received on Thursday, 30 June 2011 22:33:52 UTC