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

On Sat, Jun 30, 2012 at 5:56 PM, Rafael Weinstein <rafaelw@google.com> wrote:
> On Fri, Jun 29, 2012 at 6:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Fri, Jun 29, 2012 at 8:25 PM, Adam Klein <adamk@chromium.org> wrote:
>>> On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking <jonas@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

Received on Saturday, 30 June 2012 17:21:44 UTC