On Wed, Aug 29, 2012 at 4:05 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Fri, 15 Jun 2012, Ryosuke Niwa wrote:
> > On Fri, Jun 15, 2012 at 6:15 PM, Mihai Parparita wrote:
> > >
> > > I used MutationObservers for the first time last night (in Chrome),
> > > and I was surprised by this behavior. I was working on something that
> > > transmogrified one node into another, so having observers file during
> > > parsing would have helpful. Otherwise something like:
> > >
> > > <script>var observer = new MutationObserver(/* observer that
> > > manipulates <foo> tags */);</script>
> > > <body>
> > > ....
> > > <foo></foo>
> > > <script>
> > > /* code that acts on foo tags */
> > > </script>
> > >
> > > If I have to use DOMContentLoaded, then the code in the second
> > > <script> block would get a chance to operate on <foo> before my
> > > observer had had a chance to transmogrify it.
> >
> > That is a slightly different issue.
> >
> > There is no guarantee that your observer is called before the second
> > script element's script is executed. The only way for that to happen is
> > if the parser yielded to the event loop immediately after parsing the
> > foo element but before executing the script element.
>
> The spec actually does require that the UA "provide a stable state" before
> processing <script>s, which invokes the relevant part of the event loop.
> If mutation observers were to fire during parse, it would require those to
> fire too (it currently does not).
In my testing, Gecko doesn't behave this way: MutationRecords are delivered
at the end of any encountered <script> tags (at the end-of-microtask,
essentially), rather than before they run. If delivery-during-parse is how
we end up going, spec-wise, I think it's important for the use-cases that
we deliver before each script runs.
- Adam