W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Tue, 5 Jul 2011 15:55:28 -0700
Message-ID: <CABNRm613z2N-_KSnCyReyDjuPZbW7gmQZOpestE+OEfQLfpbCw@mail.gmail.com>
To: Olli@pettay.fi
Cc: Rafael Weinstein <rafaelw@google.com>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Adam Klein <adamk@google.com>, Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>, Webapps WG <public-webapps@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT