- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 29 Jun 2012 11:44:45 +0200
- To: olli@pettay.fi
- Cc: Adam Klein <adamk@chromium.org>, Anne van Kesteren <annevk@annevk.nl>, Ian Hickson <ian@hixie.ch>, WebApps WG <public-webapps@w3.org>
On Wed, Jun 27, 2012 at 3:31 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote: > On 06/26/2012 11:58 PM, Adam Klein wrote: >> >> On Wed, Jun 20, 2012 at 12:29 AM, Anne van Kesteren <annevk@annevk.nl >> <mailto:annevk@annevk.nl>> wrote: >> >> >> On Tue, Jun 19, 2012 at 10:52 PM, Olli Pettay <Olli.Pettay@helsinki.fi >> <mailto:Olli.Pettay@helsinki.fi>> wrote: >> > end-of-microtask or end-of-task everywhere. And yes, some parsing / >> > networking details may unfortunately be exposed, >> > but in a way which should be quite random. Web devs just can't >> really rely >> > on network packages to be delivered to parser in >> > some exact way. >> >> I think the original solution we had to not expose parser mutations >> was better. Exposing this can lead to all kinds of subtle bugs that >> are hard to detect for developers. >> >> >> I take it from your reply that you and I had the same view of what's >> specced in DOM4. > > > DOM4 doesn't say anything about this. And because it doesn't special case > parser initiated mutations, > those mutations should be there. > > >> That is, that MutationObservers are not specified to be notified >> of actions taken by the parser. > > That would be still very odd. The randomness that there is, is visible to > scripts already now. > You can't know the size of network packages, so you can't know exactly now > documents are parsed etc. > > It would be also odd for scripts which use mutation observer to start > working suddenly when > document enters into some state (readyState == "complete" or some such). > During page load user initiated events could cause all sorts of mutations > but there wasn't a way to get notified > about those. Like Olli says, the randomness is already there. It's inherent with loading content from the network. Not firing MutationObservers doesn't reduce randomness at all, it just makes it harder to deal with since you need to use polling rather than getting observer callbacks. So if the concern is that there is randomness involved with parsing, we are just doing a disservice by disabling MutationObserver callbacks. I think it would significantly reduce the reliability of the API if we don't notify about parser mutations. It basically means that MutationObservers are completely unreliable until DOMContentLoaded has fired for a document. In fact, it would likely be more understandable to say that no MutationObserver callbacks happen before DOMContentLoaded has fired, rather than making the distinction between parser mutation and non-parser mutations. Actually, the situation is even worse since even after DOMContentLoaded has fired, parser mutations can still occur. If a page opens an <iframe> and moves nodes out of it while parsing is still happening, it can result in that the <iframe>s parser making changes to the parent document, which wouldn't then notify MutationObservers. All in all I think that as soon as we introduce exceptions to when MutationObserver callbacks fire we change the API from being a reliable way to track DOM mutations to a unreliable way where all callers have to be aware of exceptions and deal with them in other ways. I.e. it feels like it significantly reduces the value of MutationObservers. And so far I don't see any good arguments made for making that reduction in value. Did I miss any arguments other then the randomness argument? / Jonas
Received on Friday, 29 June 2012 09:45:56 UTC