- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 3 Sep 2012 08:45:24 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Rafael Weinstein <rafaelw@chromium.org>, olli@pettay.fi, Ian Hickson <ian@hixie.ch>, Adam Klein <adamk@chromium.org>, Mihai Parparita <mihaip@chromium.org>, Ryosuke Niwa <rniwa@webkit.org>, WebApps WG <public-webapps@w3.org>
On Mon, Sep 3, 2012 at 1:24 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Thu, Aug 30, 2012 at 2:18 PM, Jonas Sicking <jonas@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>: > > x<script>alert(document.body.id)</script><body 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
Received on Monday, 3 September 2012 15:46:28 UTC