W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation Observers: a replacement for DOM Mutation Events

From: Adam Klein <adamk@chromium.org>
Date: Wed, 28 Sep 2011 09:01:33 -0700
Message-ID: <CAEvLGcKdm6MTkxYWAMzvjzbX86K8JkSQs1OVsJT6RwdYoNXZcA@mail.gmail.com>
To: Olli@pettay.fi
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 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:24 UTC