- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 30 Aug 2012 06:57:14 +0300
- To: Ian Hickson <ian@hixie.ch>
- CC: Adam Klein <adamk@chromium.org>, Mihai Parparita <mihaip@chromium.org>, Ryosuke Niwa <rniwa@webkit.org>, WebApps WG <public-webapps@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Jonas Sicking <jonas@sicking.cc>, Olli@pettay.fi, Rafael Weinstein <rafaelw@chromium.org>
On 08/30/2012 02:05 AM, Ian Hickson wrote: >> On Fri, Jun 15, 2012 at 4:35 PM, Adam Klein <adamk@google.com> wrote: >>> >>> This code alerts in Firefox but not in Chrome: >>> >>> <!DOCTYPE html> >>> <body> >>> <script> >>> var observer = new MutationObserver(function(r) { >>> alert(r); >>> }); >>> observer.observe(document.body, {childList: true, subtree: true}); >>> </script> >>> <p>Hello, World</p> >>> </body> >>> >>> In WebKit's implementation, we had assumed that MutationObservers were >>> meant to observe changes after page load (and I personally thought >>> that we'd specced it that way, by putting it in DOM4, not HTML). But >>> it seems the Mozilla implementors made a different assumption. But >>> what should happen? >>> >>> IMHO, it may not be worth the gain may not be worth the possible >>> performance degradation. If script wants to find out what the parser >>> put on the page, it should wait for DOMContentLoaded. But I can >>> imagine a use case where script might want to find out about the >>> parser's work during load. >>> >>> In any case, we should try to come to a decision about this, since >>> this seems to be the one major divergence between the existent >>> implementations of MutationObservers. > > 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). > > > 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). > > > On Tue, 26 Jun 2012, Adam Klein wrote: >> >> I take it from your reply that you and I had the same view of what's >> specced in DOM4. That is, that MutationObservers are not specified to be >> notified of actions taken by the parser. Given that fact, it seems that >> either the spec should be changed (and by "spec" here I think the >> required changes are in HTML, not DOM), or Firefox's implementation >> ought to be changed. >> >> Anne, Ian, Olli, Jonas, your thoughts? > > I've updated HTML to explicitly say mutation observers don't fire when > parsing, in the same way that it says not to fire mutation events. > The point is that MutationObserver can handle parsing case just fine. It doesn't have similar problems what Mutation Events have. -Olli
Received on Thursday, 30 August 2012 03:58:27 UTC