Re: [dom] mutation observer follow up

On Fri, Feb 17, 2012 at 5:55 AM, Anne van Kesteren <annevk@opera.com> wrote:
> Is there any particular reason why the "registered observer" definition is
> sometimes referred to as "registration" and sometimes as "registered
> observer"?

Only that I first thought that "registration" might suffice as an
explanation but switched to the clearer (but more verbose) "registered
observer" later (the class in WebKit is called
MutationObserverRegistration). Using one name everywhere seems fine;
if you have any ideas on a better (possibly one-word) name, I'd be
happy for suggestions.

> What is "transient" for?

It's needed to make sure observers can hear about things that happen
in a newly-disconnected tree. Imagine I want to hear when any <a> tags
leave the document, and consider the dom tree:

<div>
  <span>
    <a></a>
  </span>
</div>

where there's a subtree observer at <div>.  Now I do:

span.remove()
a.remove()

If we didn't have transient observers, the observer would only see one
record, notifying it that span was removed. But by that time, <a>
would no longer be a child of <span>, so the <a> tag would have been
removed "in secret".  That's why we need to add transient observers
every time we disconnect some node where a subtree observer exists
(note that it's required also for, e.g., attribute mutations: what if
<a>'s href attr changed while it was disconnected?).

I'll explain below how transient observers are different from normal
registered observers.

> We need to add some kind of flag to "insert"/"remove" so that "replace all"
> can have a special MutationRecord object for textContent and innerHTML and
> such (and that then "insert"/"remove" not generate additional MutationRecord
> objects).

Yes, that's a major thing that's missing. In discussion with Rafael,
we've been thinking about trying to simplify the way textContent and
innerHTML records work such that the removals and insertions would be
in different records (in WebKit, at least, this would simplify
implementation). The basic idea would be that "remove all children"
would trigger one record, and then inserting the children would
trigger a second.  I'm interested if Olli has any input on this from
an implementation perspective in Firefox.

> I'm not sure why there's a special algorithm for adding transient observers.
> How is it different from just appending a transient observer to a given
> node's list?

Are you referring to step 7 of
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-remove?

See above for why it depends on there being a subtree observer in an
ancestor's list. As for what the "transient" bit is doing on a
registered observer: at the end of each microtask, all transient
observers are removed, just before delivery to the associated
observer. So this is another bit that will make more sense once we've
got some microtask language in HTML.

> I also made various changes you should probably review (all editorial
> though, I hope!):

Thanks, will take a look at those now.

- Adam

>
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#mutation-observers
> http://dvcs.w3.org/hg/domcore/
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/

Received on Friday, 17 February 2012 18:42:33 UTC