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
