- From: Adam Klein <adamk@chromium.org>
- Date: Fri, 17 Feb 2012 10:41:59 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "www-dom@w3.org" <www-dom@w3.org>, Olli@pettay.fi
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