Re: Mutation events replacement

On 6/30/11 12:26 PM, Boris Zbarsky wrote:
> On 6/30/11 2:56 PM, David Flanagan wrote:
>> I'll add my own possibly stupid question... Can we go in the opposite
>> direction and fire mutation events immediately without queuing, but
>> forbid any DOM modifications from the event callbacks?
>
> Forbid DOM modifications to all DOMs?  Or just one DOM? 
Is it clearer is I say "forbid any modifications to the document tree"?  
I suspect that DOM Level 2 Core covers the modifications I have in mind 
when it throws NO_MODIFICATION_ALLOWED_ERR.

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.  In 
Jonas's original proposal, is the notifyingCallbacks flag per-document 
or global? (I'm assuming per-document, but the intent is not actually 
clear to me from the text).
> 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?

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.  The fact that the DOM 
already has the NO_MODIFICATION_ALLOWED_ERR infrastructure (and that it 
goes mostly unused) seems helpful.  The current proposal relies on a 
per-document notifyingCallbacks flag.  Adding a per-document 
theTreeIsLocked flag seems like it might be of comparable specification 
complexity.  (I'll defer to Boris and other about the implementation 
complexity.)

 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.

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.

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

> -Boris
>
     David

Received on Thursday, 30 June 2011 20:15:42 UTC