Re: Mutation events replacement

On Thu, Jun 30, 2011 at 1:35 PM, Boris Zbarsky <bzbarsky@mit.edu> 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