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

On 06/17/2012 10:17 PM, Ryosuke Niwa wrote:
> On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking <jonas@sicking.cc <mailto:jonas@sicking.cc>> wrote:
>
>     On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein <rafaelw@google.com <mailto: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?

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


>
> - Ryosuke
>

Received on Monday, 18 June 2012 05:23:32 UTC