Re: Mutation events replacement

On Tue, Jun 28, 2011 at 5:24 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> This new proposal solves both these by making all the modifications
> first, then firing all the events. Hence the implementation can
> separate implementing the mutating function from the code that sends
> out notifications.
>
> Conceptually, you simply queue all notifications in a queue as you're
> making modifications to the DOM, then right before returning from the
> function you insert a call like "flushAllPendingNotifications()". This
> way you don't have to care at all about what happens when those
> notifications fire.

So when exactly are these notifications going to be fired?  In
particular, I hope non-DOM Core specifications are going to have
precise control over when they're fired.  For instance, execCommand()
will ideally want to do all its mutations at once and only then fire
the notifications (which I'm told is how WebKit currently works).  How
will this work spec-wise?  Will we have hooks to say things like
"remove a node but don't fire the notifications yet", and then have to
add an extra line someplace saying to fire all the notifications?
This could be awkward in some cases.  At least personally, I often say
things like "call insertNode(foo) on the range" in the middle of a
long algorithm, and I don't want magic happening at that point just
because DOM Range fires notifications before returning from
insertNode.

Also, even if specs have precise control, I take it the idea is
authors won't, right?  If a library wants to implement some fancy
feature and be compatible with users of the library firing these
notifications, they'd really want to be able to control when
notifications are fired, just like specs want to.  In practice, the
only reason this isn't an issue with DOM mutation events is because
they can say "don't use them", and in fact people rarely do use them,
but that doesn't seem ideal -- it's just saying library authors
shouldn't bother to be robust.

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.

Received on Wednesday, 29 June 2011 14:13:59 UTC