Re: Mutation events replacement

Aryeh Gregor wrote:
> Maybe this is a stupid question, since I'm not familiar at all with
> the use-cases involved, but why can't we delay firing the
> notifications until the event loop spins?  If we're already delaying
> them such that there are no guarantees about what the DOM will look
> like by the time they fire, it seems like delaying them further
> shouldn't hurt the use-cases too much more.  And then we don't have to
> put further effort into saying exactly when they fire for each method.
>   But this is pretty obvious, so I assume there's some good reason not
> to do it.

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?  Libraries that 
simply want to keep their internal state in sync with the DOM can do 
that.  Code that really needs to modify the DOM would have to manually 
queue a task with setTimeout() to make the change later.

DOM Level 2 has the notion of readonly nodes--any attempt to modify them 
throws NO_MODIFICATION_ALLOWED_ERR. I've never understood how nodes 
became readonly, and the concept seems to have been removed from 
DOMCore, but I suppose it could be re-introduced if it allowed simpler 
mutation events.

     David

Received on Thursday, 30 June 2011 18:56:40 UTC