On Tue, Sep 27, 2011 at 1:12 PM, Olli Pettay <olli.pet...@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. > 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. - Adam