Re: Mutation events replacement

On Tue, Jul 5, 2011 at 3:24 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:

> On 07/06/2011 12:48 AM, Rafael Weinstein wrote:
>
>> On Tue, Jul 5, 2011 at 2:38 PM, Olli Pettay<Olli.Pettay@helsinki.fi**>
>>  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.

- Ryosuke

Received on Tuesday, 5 July 2011 22:56:23 UTC