Re: Should MutationObservers be able to observe work done by the HTML parser?

On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking <jonas@sicking.cc> 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.
>

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?

- Ryosuke