Re: Mutation events replacement

On 6/30/11 4:15 PM, David Flanagan wrote:
>> Forbid DOM modifications to all DOMs? Or just one DOM?
> Is it clearer is I say "forbid any modifications to the document tree"?

There are multiple document trees around is the point.

> It would be nice to only lock the document tree in which the mutation
> occurred. That seems doable to me, but maybe I'm missing something.

I think you are.  What happens if the document tree containing the 
iframe that the document you're mutating contains is modified?

>> Is window.close() forbidden? Is spinning the event loop (e.g. sync
>> XHR) forbidden?
> I wasn't intending that those be forbidden. Won't those cases be
> problematic whatever mutation event solution is adopted?

Not problematic from the point of view of the DOM implementor, since 
they will run when the system is in a consistent state.

> 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?

>> This is actually a pretty hard problem to solve, and still wouldn't
>> really solve the performance issues for DOM events....
> Still better than current DOM Mutation event, though right? Are you
> saying that synchronous callbacks on a readonly tree would have worse
> performance than Jonas's and Olli's proposal?

In Gecko's case, yes: we would need to sync various other state more to 
be ready for whatever insanity the callee script chooses to perpetrate 
other than DOM mutations (which I will posit we can just throw on if we 
want, per your proposal)...

-Boris

Received on Thursday, 30 June 2011 20:36:43 UTC