On 06/17/2012 10:17 PM, Ryosuke Niwa wrote:
On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking <jo...@sicking.cc 
<mailto:jo...@sicking.cc>> wrote:

    On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein <rafa...@google.com 
<mailto: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:
     > 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.

Agreed. I'm in favor of observers being notified for parser-initiated DOM 
mutations. The primary reason we don't fire mutation events for parser
insertion & removal is because they're synchronous and introduces all sorts of 
problems including security vulnerabilities but that isn't the case
with mutation observers.

One question. Should we also notify mutation observers immediately before 
executing synchronous scripts (i.e. script elements without differ or async
content attributes) to address Mihai's use case?

That would be rather odd. If someone needs to process mutation records before 
normal delivery time, there is always takeRecords()

- Ryosuke

Reply via email to