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

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.


-Olli

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