On 06/17/2012 03:03 PM, Jonas Sicking wrote:
On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein <rafa...@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:


"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 
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

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

/ Jonas

Reply via email to