Re: Mutation events replacement

On Tue, Jul 5, 2011 at 3:55 PM, Ryosuke Niwa <> wrote:
> On Tue, Jul 5, 2011 at 3:24 PM, Olli Pettay <> wrote:
>> On 07/06/2011 12:48 AM, Rafael Weinstein wrote:
>>> On Tue, Jul 5, 2011 at 2:38 PM, Olli Pettay<>
>>>  wrote:
>>>> What is the reason to require a new mechanism for async handling? Could
>>>> listeners be handled in a task?Basically, if DOM is mutated during task A, a
>>>> new task, B, is scheduled and all the mutation listeners will be
>>>> called there.
>>> It's too late by then. Most importantly, visual artifacts of incomplete
>>> DOM work may have been seen by the user.
>> If that is the reason, I don't think it really holds. The script may force
>> a layout flush right after DOM mutation and then cause some popup to shows
>> up which may cause repainting in the main page.
> Layout is different from paint at least in WebKit.
> But I agree with you that if any observer calls alert, showModalDialog, and
> other APIs that forces repaint, you can't really do anything about it.
>  Also, UA vendors can decide to delay the repaint until all mutation
> observers are called in common cases even if they were completely
> asynchronous.

It seems like these are rarified enough cases that visual artifacts
are acceptable collateral damage if you do this. [Put another way, if
you care enough about the visual polish of your app that you will put
energy into avoiding flickr, you probably aren't using alert and
showModalDialog anyway].

Also, it's up to the app when to do it, so it's entirely in its
control (and thus avoid visual artifacts).

Note that this is a problem with both proposals. Work done in (at
least some) mutation observers is delayed. If a sync paint occurs
before it, it's work won't be reflected on the screen.

> - Ryosuke

Received on Wednesday, 6 July 2011 00:27:56 UTC