- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 28 Sep 2011 19:23:10 +0300
- To: Adam Klein <adamk@chromium.org>
- CC: public-webapps@w3.org, Ojan Vafai <ojan@chromium.org>, rafaelw@chromium.org, rniwa@chromium.org, Jonas Sicking <jonas@sicking.cc>, annevk@opera.com, arv@chromium.org
On 09/28/2011 07:01 PM, Adam Klein wrote: > On Tue, Sep 27, 2011 at 1:12 PM, Olli Pettay<Olli.Pettay@helsinki.fi> wrote: >> On 09/24/2011 12:16 AM, Adam Klein wrote: >>> >>> For each observer, if a registration exists which requests the >>> matching mutation type and whose observed node set contains the target >>> node of the mutation, a MutationRecord is appended to the observer's >>> pending mutation queue. If multiple such registrations exist for a >>> given observer, a single MutationRecord is delivered having the union >>> of the information requested by all registrations (e.g. >>> attributeOldValue). >> >> >> This is actually still ambiguous. >> What if attributeOldValue is first set to true for document.documentElement, >> and then false (implicitly or explicitly) >> for document, should attribute values be reported? >> >> Another problematic case is that if we have subtree A and B and both >> are being observed by same observer but different options. Then some >> node from A is moved to B. Which options should be used? >> >> So, should we define that "union" means that 'true' values override >> 'false' values, and attributeFilter values are union'ed the usual way? > > Yes, I think this is what I actually had in mind: true values override > false values. Actually attributeFilter is union'ed the usual way only if it is defined always (in all the options). If it is missing, all the attributes should be observed. > >> To make API somewhat more consistent, should we change >> "Subsequent calls to the same MutationObserver made with the same |target| >> have the effect of resetting the options associated with the registration. " >> to follow the union-ing. > > If we're going to do that, I think we need to add the ability to stop > listening to a single target (rather than disconnecting from all). > But I'm not convinced we need this consistency, as I suspect the above > case (covering multiple nodes with different registrations and > different options) is quite unusual. OK, let's keep the re-observe a target the way it is. -Olli > > - Adam >
Received on Wednesday, 28 September 2011 16:24:16 UTC