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

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

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 30 Aug 2012 06:57:14 +0300
Message-ID: <503EE49A.3090709@helsinki.fi>
To: Ian Hickson <ian@hixie.ch>
CC: Adam Klein <adamk@chromium.org>, Mihai Parparita <mihaip@chromium.org>, Ryosuke Niwa <rniwa@webkit.org>, WebApps WG <public-webapps@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Jonas Sicking <jonas@sicking.cc>, Olli@pettay.fi, Rafael Weinstein <rafaelw@chromium.org>
On 08/30/2012 02:05 AM, Ian Hickson wrote:
>> On Fri, Jun 15, 2012 at 4:35 PM, Adam Klein <adamk@google.com> wrote:
>>> This code alerts in Firefox but not in Chrome:
>>> <!DOCTYPE html>
>>> <body>
>>>    <script>
>>>      var observer = new MutationObserver(function(r) {
>>>        alert(r);
>>>      });
>>>      observer.observe(document.body, {childList: true, subtree: true});
>>>    </script>
>>>    <p>Hello, World</p>
>>> </body>
>>> In WebKit's implementation, we had assumed that MutationObservers were
>>> meant to observe changes after page load (and I personally thought
>>> that we'd specced it that way, by putting it in DOM4, not HTML). But
>>> it seems the Mozilla implementors made a different assumption. But
>>> what should happen?
>>> IMHO, it may not be worth the gain may not be worth the possible
>>> performance degradation. If script wants to find out what the parser
>>> put on the page, it should wait for DOMContentLoaded. But I can
>>> imagine a use case where script might want to find out about the
>>> parser's work during load.
>>> In any case, we should try to come to a decision about this, since
>>> this seems to be the one major divergence between the existent
>>> implementations of MutationObservers.
> The spec used to say "DOM mutation events must not fire for changes caused
> by the UA parsing the document". I've updated this to also mention
> mutation observers.

Why? Getting MutationObserver notifications during parsing is what I'd expect
the API to provide (and that is implemented in Gecko).

> On Fri, 15 Jun 2012, Ryosuke Niwa wrote:
>> On Fri, Jun 15, 2012 at 6:15 PM, Mihai Parparita wrote:
>>> I used MutationObservers for the first time last night (in Chrome),
>>> and I was surprised by this behavior. I was working on something that
>>> transmogrified one node into another, so having observers file during
>>> parsing would have helpful. Otherwise something like:
>>> <script>var observer = new MutationObserver(/* observer that
>>> manipulates <foo> tags */);</script>
>>> <body>
>>> ....
>>> <foo></foo>
>>> <script>
>>>   /* code that acts on foo tags */
>>> </script>
>>> If I have to use DOMContentLoaded, then the code in the second
>>> <script> block would get a chance to operate on <foo> before my
>>> observer had had a chance to transmogrify it.
>> That is a slightly different issue.
>> There is no guarantee that your observer is called before the second
>> script element's script is executed. The only way for that to happen is
>> if the parser yielded to the event loop immediately after parsing the
>> foo element but before executing the script element.
> The spec actually does require that the UA "provide a stable state" before
> processing <script>s, which invokes the relevant part of the event loop.
> If mutation observers were to fire during parse, it would require those to
> fire too (it currently does not).
> On Tue, 26 Jun 2012, Adam Klein wrote:
>> I take it from your reply that you and I had the same view of what's
>> specced in DOM4. That is, that MutationObservers are not specified to be
>> notified of actions taken by the parser. Given that fact, it seems that
>> either the spec should be changed (and by "spec" here I think the
>> required changes are in HTML, not DOM), or Firefox's implementation
>> ought to be changed.
>> Anne, Ian, Olli, Jonas, your thoughts?
> I've updated HTML to explicitly say mutation observers don't fire when
> parsing, in the same way that it says not to fire mutation events.

The point is that MutationObserver can handle parsing case just fine.
It doesn't have similar problems what Mutation Events have.

Received on Thursday, 30 August 2012 03:58:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 14:37:00 UTC