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.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