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: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 17 Jun 2012 14:03:06 +0200
Message-ID: <CA+c2ei_3X2gLsX8YRxo4i+F3CnPwsfeTkM3Eqyk0v1rWH1AhwQ@mail.gmail.com>
To: Rafael Weinstein <rafaelw@google.com>
Cc: Ryosuke Niwa <rniwa@webkit.org>, Mihai Parparita <mihaip@chromium.org>, Adam Klein <adamk@chromium.org>, WebApps WG <public-webapps@w3.org>, Olli@pettay.fi
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.

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
Received on Sunday, 17 June 2012 12:04:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC