Re: Should MutationObservers be able to observe work done by the HTML parser?
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 scripts, 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. `._.-(,_..'--(,_..'`-.;.'
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Tue, Sep 4, 2012 at 10:11 PM, Elliott Sprehn espr...@gmail.com wrote: On Mon, Sep 3, 2012 at 8:45 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 3, 2012 at 1:24 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 30, 2012 at 2:18 PM, Jonas Sicking jo...@sicking.cc wrote: ... ... But I'm also not very worried about small differences in implementations here as long as everyone maintains the invariants that mutation observers set out to hold. Pages can't depend on an exact set of mutations happening anyway due to the stochastic nature of parsing. It concerns me to require consistent records for mutations except in parsing. Does this concern you more than simply not creating any mutation records while parsing. I.e. does it concern you more than the currently specced behavior of always creating mutation records except in parsing? I would think it's more likely that pages break over not being notified about certain mutations at all, than that they break over being notified about different records that add up to the same set of mutations. Especially when the records is going to vary from page load to page load anyway. While the batches of mutation records might be different based on when the parser yields, the same records should still be generated from parsing the same document in each browser. Especially if you're following the HTML5 parser algorithm... This is true. Though keep in mind that even if two people are both using HTML5 compliant browsers, and load the same document while observing the set of states that the page goes through, those two people will see the page transition through different DOM states. This can be the case even if the two people are using the exact same HTML parser implementations due to network packet boundaries being different, and due to timing effects being different. But if this truly is a concern, I'm absolutely fine with defining which coalescing we should do when creating mutation records from the parser. That is in my opinion a far better solution than simply not firing mutations notifications at all during parsing. / Jonas
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Mon, Sep 3, 2012 at 8:45 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 3, 2012 at 1:24 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 30, 2012 at 2:18 PM, Jonas Sicking jo...@sicking.cc wrote: ... ... But I'm also not very worried about small differences in implementations here as long as everyone maintains the invariants that mutation observers set out to hold. Pages can't depend on an exact set of mutations happening anyway due to the stochastic nature of parsing. It concerns me to require consistent records for mutations except in parsing. While the batches of mutation records might be different based on when the parser yields, the same records should still be generated from parsing the same document in each browser. Especially if you're following the HTML5 parser algorithm... - E
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Thu, Aug 30, 2012 at 2:18 PM, Jonas Sicking jo...@sicking.cc wrote: 1. We make sure to set all element attributes before inserting the element into the DOM. This to avoid sending notifications for attribute modifications. The element is inserted with the right set of attributes from the get-go. That's not possible for e.g. body: xscriptalert(document.body.id)/scriptbody id=test -- http://annevankesteren.nl/
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Mon, Sep 3, 2012 at 1:24 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 30, 2012 at 2:18 PM, Jonas Sicking jo...@sicking.cc wrote: 1. We make sure to set all element attributes before inserting the element into the DOM. This to avoid sending notifications for attribute modifications. The element is inserted with the right set of attributes from the get-go. That's not possible for e.g. body: xscriptalert(document.body.id)/scriptbody id=test Yes, I was simplifying a bit. For head and body we do indeed set attributes on already-inserted elements. In which case we do add the appropriate attribute-change mutation record. I also skipped over how we handle things like improperly nested start and end tags which can cause the HTML parser to move around already-inserted elements. And how to handle nodes being inserted other than at the end of the document due to misplaced content in a table. I forget what we do in these situations. You could definitely imagine coalescing notifications here too if we for example haven't yet returned to the event loop since inserting the table, in which case it'd just look like the moved content was inserted before the table was. The point is that we always maintain the invariants that mutation observers guarantee. It's very possible to optimize and reduce the number of notifications to a relatively small number without introducing a lot of complexity in the parser. I'll also note that this isn't introducing any more stochastic behavior than HTML parsing already has. I.e. someone polling the DOM from a timer or from UI events is already seeing different behavior both in different browsers and on different clients due to where things like network packet boundaries end up. If we really wanted to specify as much detail as we could, we could specify that the smallest number of mutation records should be created any time the parser runs. I.e. we could specify that the implementation must implement all optimizations regarding handling of adoption agency algorithm etc. I think this would be very implementable without a lot of complexity in the parser at least in Gecko. But I'm also not very worried about small differences in implementations here as long as everyone maintains the invariants that mutation observers set out to hold. Pages can't depend on an exact set of mutations happening anyway due to the stochastic nature of parsing. / Jonas
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Fri, Jun 29, 2012 at 6:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jun 29, 2012 at 8:25 PM, Adam Klein ad...@chromium.org wrote: On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking jo...@sicking.cc wrote: 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? Performance was one concern that's come up in discussing this with Ojan and Rafael. Imagine a MutationObserver attached to the document near the top of the page. Now we need to create basically one MutationRecord per node inserted (because the parser operates in a depth-first sort of order). I'm not at all sure this is a show-stopper (we might be able to introduce some new MutationRecord type that could compactly represent parser-style operation), but it definitely seems worrisome, especially given that one of the common uses for MutationObservers is extensions which might run on many (all?) pages. Hmm.. is there actually anything requiring that nodes are inserted one at a time? Internally in mozilla we do insert nodes one at a time, but the notifications we send out to the various subsystems make it seem like nodes are inserted in big chunks. This has previously been to Are the chunks arbitrarily shaped fragments? I.e. is their any restriction on their shape other than a tree? give us good performance from the layout engine which benefits from getting notified by large chunks being inserted rather than nodes being inserted one at a time. The MutationObserver implementation hangs off of the same notification system and thus also sees nodes as being inserted in big chunks. / Jonas
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Sat, Jun 30, 2012 at 5:56 PM, Rafael Weinstein rafa...@google.com wrote: On Fri, Jun 29, 2012 at 6:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jun 29, 2012 at 8:25 PM, Adam Klein ad...@chromium.org wrote: On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking jo...@sicking.cc wrote: 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? Performance was one concern that's come up in discussing this with Ojan and Rafael. Imagine a MutationObserver attached to the document near the top of the page. Now we need to create basically one MutationRecord per node inserted (because the parser operates in a depth-first sort of order). I'm not at all sure this is a show-stopper (we might be able to introduce some new MutationRecord type that could compactly represent parser-style operation), but it definitely seems worrisome, especially given that one of the common uses for MutationObservers is extensions which might run on many (all?) pages. Hmm.. is there actually anything requiring that nodes are inserted one at a time? Internally in mozilla we do insert nodes one at a time, but the notifications we send out to the various subsystems make it seem like nodes are inserted in big chunks. This has previously been to Are the chunks arbitrarily shaped fragments? I.e. is their any restriction on their shape other than a tree? We only perform valid DOM operations, which means that we're restricted to mutating Text nodes and inserting things that a DocumentFragment can express. I.e. we only consecutive siblings, though these siblings can have arbitrarily big subtrees. So if we're parsing a document like: div p span...lots of nodes here.../span span...more content here.../span /p form...lots of nodes here.../form footer...enough with the content already.../footer /div and a network boundary falls after the start p tag, then we'll first do a single insertion which looks like div p/p /div then once we receive more content we'll do a single insertion containing the two span elements: div p span...lots of nodes here.../span span...more content here.../span /p /div then do a single insertion containing the form and the footer div p span...lots of nodes here.../span span...more content here.../span /p form...lots of nodes here.../form footer...enough with the content already.../footer /div So all in all 3 MutationObserver records would be created in this instance. / Jonas
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Wed, Jun 27, 2012 at 3:31 PM, Olli Pettay olli.pet...@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 ann...@annevk.nl mailto:ann...@annevk.nl wrote: On Tue, Jun 19, 2012 at 10:52 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@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 iframes 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
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking jo...@sicking.cc wrote: 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? Performance was one concern that's come up in discussing this with Ojan and Rafael. Imagine a MutationObserver attached to the document near the top of the page. Now we need to create basically one MutationRecord per node inserted (because the parser operates in a depth-first sort of order). I'm not at all sure this is a show-stopper (we might be able to introduce some new MutationRecord type that could compactly represent parser-style operation), but it definitely seems worrisome, especially given that one of the common uses for MutationObservers is extensions which might run on many (all?) pages. - Adam
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Fri, Jun 29, 2012 at 8:25 PM, Adam Klein ad...@chromium.org wrote: On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking jo...@sicking.cc wrote: 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? Performance was one concern that's come up in discussing this with Ojan and Rafael. Imagine a MutationObserver attached to the document near the top of the page. Now we need to create basically one MutationRecord per node inserted (because the parser operates in a depth-first sort of order). I'm not at all sure this is a show-stopper (we might be able to introduce some new MutationRecord type that could compactly represent parser-style operation), but it definitely seems worrisome, especially given that one of the common uses for MutationObservers is extensions which might run on many (all?) pages. Hmm.. is there actually anything requiring that nodes are inserted one at a time? Internally in mozilla we do insert nodes one at a time, but the notifications we send out to the various subsystems make it seem like nodes are inserted in big chunks. This has previously been to give us good performance from the layout engine which benefits from getting notified by large chunks being inserted rather than nodes being inserted one at a time. The MutationObserver implementation hangs off of the same notification system and thus also sees nodes as being inserted in big chunks. / Jonas
Re: Should MutationObservers be able to observe work done by the HTML parser?
On 06/26/2012 11:58 PM, Adam Klein wrote: On Wed, Jun 20, 2012 at 12:29 AM, Anne van Kesteren ann...@annevk.nl mailto:ann...@annevk.nl wrote: On Tue, Jun 19, 2012 at 10:52 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@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. 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? - Adam
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Wed, Jun 20, 2012 at 12:29 AM, Anne van Kesteren ann...@annevk.nlwrote: On Tue, Jun 19, 2012 at 10:52 PM, Olli Pettay olli.pet...@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. 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? - Adam
Re: Should MutationObservers be able to observe work done by the HTML parser?
On 06/20/2012 10:36 AM, Ryosuke Niwa wrote:
On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
Ojan points out
that simply using end-of-task could expose low-level implementation
detail of the parser to script (such as how much parsing is done in a
single task
before the parser yields).
Does Firefox do anything special here? Or does it simply use the same
end-of-task delivery as everywhere else?
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.
That randomness seems undesirable. Can we delay the delivery until
DOMContentLoaded is fired so that we can have more consisnte behavior here?
Well, the randomness is about the same randomness which is exposed to web pages
already.
img src=http://www.example.org/nonexisting.png;
onerror=console.log('img')
scriptconsole.log('script')/script
the order of 'img' and 'script' in the console is random.
-Olli
- Ryosuke
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Tue, Jun 19, 2012 at 10:52 PM, Olli Pettay olli.pet...@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. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fiwrote: Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? 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. That randomness seems undesirable. Can we delay the delivery until DOMContentLoaded is fired so that we can have more consisnte behavior here? - Ryosuke
Re: Should MutationObservers be able to observe work done by the HTML parser?
On 06/20/2012 10:36 AM, Ryosuke Niwa wrote: On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? 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. That randomness seems undesirable. Can we delay the delivery until DOMContentLoaded is fired so that we can have more consisnte behavior here? That prevents using MutationObserver for certain cases. Like when you stream data using an iframe. Also, there are already many cases when networking/parsing handling is exposed to the web pages. Just put any img onload=.. onerror= When the handlers run, the stuff after the img may or may not be in the document. - Ryosuke
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Wed, Jun 20, 2012 at 12:36 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fiwrote: Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? 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. That randomness seems undesirable. Can we delay the delivery until DOMContentLoaded is fired so that we can have more consisnte behavior here? This doesn't seem very useful to me. Observing during page load will clearly have a cost associated with it, and if you aren't notified until DOMContentLoaded, you could have just listened for DOMContentLoaded yourself, looked through the document for the stuff you care about, and then attach an observer. I'm not entirely opposed to notifying of parse-time mutations, but if we did it seems like we'd want to deliver them during page load in some way. - Adam
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Wed, Jun 20, 2012 at 1:33 PM, Adam Klein ad...@chromium.org wrote: On Wed, Jun 20, 2012 at 12:36 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fiwrote: Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? 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. That randomness seems undesirable. Can we delay the delivery until DOMContentLoaded is fired so that we can have more consisnte behavior here? This doesn't seem very useful to me. Observing during page load will clearly have a cost associated with it, and if you aren't notified until DOMContentLoaded, you could have just listened for DOMContentLoaded yourself, looked through the document for the stuff you care about, and then attach an observer. That's a good point. Although my point was so that you don't have to explicitly wait for DOMContentLoaded yourself. Because if that was script's intention, you could have just added differ or async content attribute to the script element. On Wed, Jun 20, 2012 at 12:53 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 06/20/2012 10:36 AM, Ryosuke Niwa wrote: That randomness seems undesirable. Can we delay the delivery until DOMContentLoaded is fired so that we can have more consisnte behavior here? That prevents using MutationObserver for certain cases. Like when you stream data using an iframe. Also, there are already many cases when networking/parsing handling is exposed to the web pages. Just put any img onload=.. onerror= When the handlers run, the stuff after the img may or may not be in the document. That's true. Maybe this randomness is okay after all. - Ryosuke
Re: Should MutationObservers be able to observe work done by the HTML parser?
* Jonas Sicking wrote: I can't think of any cases where you would *not* want these to fire for parser mutations. For example if you are building an XBL-like widget library which uses the DOM under a node to affect behavior or rendering of some other object. If you attach the widget before the node is fully parsed you still need to know about modifications that happen due to parsing. And you would typically want to attach early to avoid cannot click button while page is loading-style issues in such a scenario. I also note that making page load a special case likely means authors have to write special code to handle it, and that does not seem desirable. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. Agreed. I'm in favor of observers being notified for parser-initiated DOM mutations. The primary reason we don't fire mutation events for parser insertion removal is because they're synchronous and introduces all sorts of problems including security vulnerabilities but that isn't the case with mutation observers. One question. Should we also notify mutation observers immediately before executing synchronous scripts (i.e. script elements without differ or async content attributes) to address Mihai's use case? This is one part of a more general question (raised by Ojan on webkit.org/b/89351): what should the timing be for delivery of these parser-initiated mutations? Mihai's use case is one example where we might want something other than end-of-task delivery. Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? - Adam
Re: Should MutationObservers be able to observe work done by the HTML parser?
On 06/19/2012 11:37 PM, Adam Klein wrote: On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking jo...@sicking.cc mailto:jo...@sicking.cc wrote: On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com mailto:rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. Agreed. I'm in favor of observers being notified for parser-initiated DOM mutations. The primary reason we don't fire mutation events for parser insertion removal is because they're synchronous and introduces all sorts of problems including security vulnerabilities but that isn't the case with mutation observers. One question. Should we also notify mutation observers immediately before executing synchronous scripts (i.e. script elements without differ or async content attributes) to address Mihai's use case? This is one part of a more general question (raised by Ojan on webkit.org/b/89351 http://webkit.org/b/89351): what should the timing be for delivery of these parser-initiated mutations? Mihai's use case is one example where we might want something other than end-of-task delivery. Mihai's use case is related to https://www.w3.org/Bugs/Public/show_bug.cgi?id=17529 (where I think Gecko's behavior is the good one) If we start to call mutation callbacks right before script execution, we would need to handle cases when script element is moved in the DOM right before script execution etc. Ugly stuff. Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? 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. - Adam
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. For example if you are building an XBL-like widget library which uses the DOM under a node to affect behavior or rendering of some other object. If you attach the widget before the node is fully parsed you still need to know about modifications that happen due to parsing. If you are tracking all nodes which has a particular class name or element name (for example to attach behavior to them, or as a performance improvement in order to keep a live list of nodes matching a selector) then you need to know about mutations that the parser performed. Also, if changing code from using document.write to using .insertAdjecentHTML or other DOM features, why should that change whether observers are notified? Are there use cases for *not* wanting to know about parser mutations, but still know about script-initiated mutations? What about situations when a node is moved around and so that parser ends up inserting nodes not at the end of the document? I.e. if a node A is done parsing, but then an ancestor B of the current parser insertion point is moved to become a child of A, which causes the parser to again mutate A's descendants. / Jonas
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. Agreed. I'm in favor of observers being notified for parser-initiated DOM mutations. The primary reason we don't fire mutation events for parser insertion removal is because they're synchronous and introduces all sorts of problems including security vulnerabilities but that isn't the case with mutation observers. One question. Should we also notify mutation observers immediately before executing synchronous scripts (i.e. script elements without differ or async content attributes) to address Mihai's use case? - Ryosuke
Re: Should MutationObservers be able to observe work done by the HTML parser?
On 06/17/2012 03:03 PM, Jonas Sicking wrote: On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. I agree. Better to try to keep the API consistent and create mutation records for all the mutations. For example if you are building an XBL-like widget library which uses the DOM under a node to affect behavior or rendering of some other object. If you attach the widget before the node is fully parsed you still need to know about modifications that happen due to parsing. If you are tracking all nodes which has a particular class name or element name (for example to attach behavior to them, or as a performance improvement in order to keep a live list of nodes matching a selector) then you need to know about mutations that the parser performed. Also, if changing code from using document.write to using .insertAdjecentHTML or other DOM features, why should that change whether observers are notified? Are there use cases for *not* wanting to know about parser mutations, but still know about script-initiated mutations? What about situations when a node is moved around and so that parser ends up inserting nodes not at the end of the document? I.e. if a node A is done parsing, but then an ancestor B of the current parser insertion point is moved to become a child of A, which causes the parser to again mutate A's descendants. / Jonas
Re: Should MutationObservers be able to observe work done by the HTML parser?
On 06/17/2012 10:17 PM, Ryosuke Niwa wrote: On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking jo...@sicking.cc mailto:jo...@sicking.cc wrote: On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com mailto:rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. Agreed. I'm in favor of observers being notified for parser-initiated DOM mutations. The primary reason we don't fire mutation events for parser insertion removal is because they're synchronous and introduces all sorts of problems including security vulnerabilities but that isn't the case with mutation observers. One question. Should we also notify mutation observers immediately before executing synchronous scripts (i.e. script elements without differ or async content attributes) to address Mihai's use case? That would be rather odd. If someone needs to process mutation records before normal delivery time, there is always takeRecords() - Ryosuke
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Sun, Jun 17, 2012 at 10:22 PM, Olli Pettay olli.pet...@helsinki.fiwrote: That would be rather odd. If someone needs to process mutation records before normal delivery time, there is always takeRecords() In my example, I don't control the contents of the second script tag, so I can't use takeRecords() there. Mihai
