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

On 06/17/2012 03:03 PM, Jonas Sicking wrote:
> On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein <rafaelw@google.com> wrote:
>> I too thought we had intentionally spec'd them to not fire during load.
>>
>> The HTML spec is clear about this WRT Mutation Events:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/#tree-construction:
>>
>> "DOM mutation events must not fire for changes caused by the UA
>> parsing the document. (Conceptually, the parser is not mutating the
>> DOM, it is constructing it.) This includes the parsing of any content
>> inserted using document.write() and document.writeln() calls."
>>
>> It seems like this should also apply to Mutation Observers, unless we
>> have compelling reasons to do otherwise.
>
> This was something that we got people complaining about with mutation
> events over the years. Our answer used to be that mutation events
> generally suck and you can't depend on them anyway. Obviously not an
> argument we'd want to use for MutationObservers.
>
> I can't think of any cases where you would *not* want these to fire
> for parser mutations.

I agree. Better to try to keep the API consistent and create mutation records for
all the mutations.





>
> For example if you are building an XBL-like widget library which uses
> the DOM under a node to affect behavior or rendering of some other
> object. If you attach the widget before the node is fully parsed you
> still need to know about modifications that happen due to parsing.
>
> If you are tracking all nodes which has a particular class name or
> element name (for example to attach behavior to them, or as a
> performance improvement in order to keep a live list of nodes matching
> a selector) then you need to know about mutations that the parser
> performed.
>
> Also, if changing code from using document.write to using
> .insertAdjecentHTML or other DOM features, why should that change
> whether observers are notified?
>
> Are there use cases for *not* wanting to know about parser mutations,
> but still know about script-initiated mutations? What about situations
> when a node is moved around and so that parser ends up inserting nodes
> not at the "end" of the document? I.e. if a node A is "done" parsing,
> but then an ancestor B of the current parser insertion point is moved
> to become a child of A, which causes the parser to again mutate A's
> descendants.
>
> / Jonas
>

Received on Monday, 18 June 2012 05:19:28 UTC