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
Received on Thursday, 6 September 2012 22:14:28 UTC