W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Should MutationObservers be able to observe work done by the HTML parser?

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 3 Sep 2012 08:45:24 -0700
Message-ID: <CA+c2ei86EShexfAgwyr0Z1zE-aykx5cUqHh8TGeCtVxPw8oDfw@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT