- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 23 Oct 2012 22:24:21 +0000 (UTC)
- To: olli@pettay.fi, Jonas Sicking <jonas@sicking.cc>, Rafael Weinstein <rafaelw@chromium.org>, Elliott Sprehn <esprehn@gmail.com>, Rafael Weinstein <rafaelw@google.com>, Adam Klein <adamk@chromium.org>
- cc: WebApps WG <public-webapps@w3.org>, Mihai Parparita <mihaip@chromium.org>, Ryosuke Niwa <rniwa@webkit.org>, Anne van Kesteren <annevk@annevk.nl>, Olli Pettay <Olli.Pettay@helsinki.fi>
On Thu, 30 Aug 2012, Olli Pettay wrote: > > > > The spec used to say "DOM mutation events must not fire for changes > > caused by the UA parsing the document". I've updated this to also > > mention mutation observers. > > Why? Getting MutationObserver notifications during parsing is what I'd > expect the API to provide (and that is implemented in Gecko). My original change was motivated just by inertia and conservatism, wanting to keep the intent of the spec unchanged. On Thu, 30 Aug 2012, Jonas Sicking wrote: > > Indeed. I have the same questions. The API doesn't have same performance > and re-entrancy problems that caused us to disable mutation events. > > If we don't fire mutation observers during parsing it means that you > basically can't rely on mutation observers at all until after the > DOMContentLoaded event has fired. In fact, you can't rely on them even > past then since if another page is loaded in an <iframe> and nodes are > moved from that iframe to your document, you won't be notified about > changes done by the parser to those nodes. > > So this change removes the ability to guarantee that you can track > mutations done to a document, which was one of the big advantages that > MutationObservers had over mutation events. I.e. mutation events only > let you track mutations to your document as long as those mutations > "behaved well", i.e. weren't done from inside mutation observers. With > this we add a similar requirement to mutation observers that they are > only reliable as long as pages "behave well" and don't move nodes from a > document which is being parsed. > > Just like mutation events solved the use cases of many authors, mutation > observers will solve the use cases of many authors even with this > change. However it will miss edge cases which I think is really > unfortunate. This seems pretty convincing. I've changed the spec accordingly. On Thu, 6 Sep 2012, Adam Klein wrote: > > > > 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. Fixed this also. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 23 October 2012 22:24:44 UTC