W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: Should MutationObservers be able to observe work done by the HTML parser?

From: Adam Klein <adamk@chromium.org>
Date: Wed, 20 Jun 2012 13:33:34 -0700
Message-ID: <CAEvLGcJ7LcH2j=oEW1MWNwBow_Rkw_z=qrZhea4-+=SkQj5=_Q@mail.gmail.com>
To: Ryosuke Niwa <rniwa@webkit.org>
Cc: olli@pettay.fi, Jonas Sicking <jonas@sicking.cc>, Rafael Weinstein <rafaelw@google.com>, Mihai Parparita <mihaip@chromium.org>, WebApps WG <public-webapps@w3.org>
On Wed, Jun 20, 2012 at 12:36 AM, Ryosuke Niwa <rniwa@webkit.org> wrote:

> On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:
>>
>>   Ojan points out
>>
>>> that simply using end-of-task could expose low-level implementation
>>> detail of the parser to script (such as how much parsing is done in a
>>> single task
>>> before the parser yields).
>>>
>>> Does Firefox do anything special here? Or does it simply use the same
>>> end-of-task delivery as everywhere else?
>>>
>>
>> end-of-microtask or end-of-task everywhere. And yes, some parsing /
>> networking details may unfortunately be exposed, but in a way which should
>> be quite random. Web devs just can't really rely on network packages to be
>> delivered to parser in some exact way.
>>
>
> That randomness seems undesirable. Can we delay the delivery until
> DOMContentLoaded is fired so that we can have more consisnte behavior here?
>

This doesn't seem very useful to me. Observing during page load will
clearly have a cost associated with it, and if you aren't notified until
DOMContentLoaded, you could have just listened for DOMContentLoaded
yourself, looked through the document for the stuff you care about, and
then attach an observer.

I'm not entirely opposed to notifying of parse-time mutations, but if we
did it seems like we'd want to deliver them during page load in some way.

- Adam
Received on Wednesday, 20 June 2012 20:34:03 GMT

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