Re: [dom] mutation observer follow up

On 02/17/2012 08:41 PM, Adam Klein wrote:
> 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.


That feels a bit strange. Either we collect the changes to one
record (both removals and insertions) or we create separate
record for all the changes (one record for each node removal etc.)
The latter would be easier for implementation, but would lead to
tons of records.
So, at least atm I'd prefer having just one record for 
textContent/innerHTML -like mutations



-Olli
>
>> 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:53:10 UTC