- From: David Flanagan <dflanagan@mozilla.com>
- Date: Thu, 30 Jun 2011 11:56:12 -0700
- To: public-webapps <public-webapps@w3.org>
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