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

Re: Mutation Observers: a replacement for DOM Mutation Events

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 28 Sep 2011 19:23:10 +0300
Message-ID: <4E8349EE.3010700@helsinki.fi>
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.


> - Adam
Received on Wednesday, 28 September 2011 16:24:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:35 UTC