- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 17 Jun 2012 14:03:06 +0200
- 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 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 Sunday, 17 June 2012 12:04:06 UTC