- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Mon, 18 Jun 2012 08:18:45 +0300
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Rafael Weinstein <rafaelw@google.com>, Ryosuke Niwa <rniwa@webkit.org>, Mihai Parparita <mihaip@chromium.org>, Adam Klein <adamk@chromium.org>, WebApps WG <public-webapps@w3.org>
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