Re: Mutation Observers: a replacement for DOM Mutation Events

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.

> 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

Received on Wednesday, 28 September 2011 16:02:17 UTC