Re: DOM Mutation Events Replacement: When to deliver mutations

On 08/11/2011 06:13 PM, Rafael Weinstein wrote:
>> Con:
>> Since the approach is bound to tasks, it is not clear what should happen
>> if event loop spins while handling the task. What if some other task
>> modifies the DOM[1], when should the mutation callbacks fire?
>> Because of this issue, tasks, which may spin event loop, should not
>> also modify DOM since that may cause some unexpected result.
> I think the *pro* side of this you listed is more fair. Both Options 2
> &  3 must answer this question. It's true that because Option 3 is
> later, it sort of has this issue "more".
And it has a lot "more". Since for example when handling an event, all
the listeners for it are called in the same task and if one event
listener modifies DOM and some other spins event loop, it is hard to
see what is causing the somewhat unexpected behavior.

> However, "what should happen" has been defined. In both cases, if
> there are any mutations which are queued for delivery when an inner
> event loop spins up, they are *not* delivered inside the inner event
> loop. In both Options, they are always delivered in the loop which
> queued them.
But what happens when event loop spins within a task, and some
"inner" task causes new mutations?
We want to notify about mutations in the order they have happened, right?
So if there are pending mutations to notify, the inner task must just
queue notifications to the queue of the outermost task.
This could effectively disable all the mutation callbacks for example 
when a modal dialog (showModalDialog) is open.

Option 2 has similar problem, but *only* while handling mutation 
callbacks, not during the whole task.


>> Callback handling is moved far away from the actual mutation.
>> Pro:
>> Can batch more, since the callbacks are called later than in
>> option 2.
>> -Olli
>> [1] showModalDialog("javascript:opener.document.body.textContent = '';", "",
>> "");

Received on Thursday, 11 August 2011 16:13:11 UTC