W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: Extending Mutation Observers to address use cases of

From: Ryosuke Niwa <rniwa@apple.com>
Date: Tue, 11 Feb 2014 21:30:53 -0800
Cc: "public-webapps@w3.org WG" <public-webapps@w3.org>, Erik Arvidsson <arv@google.com>, Anne van Kesteren <annevk@annevk.nl>, Jonas Sicking <jonas@sicking.cc>, Rafael Weinstein <rafaelw@google.com>, Adam Klein <adamk@google.com>
Message-id: <CC5E816F-7058-46AA-91BF-296D18BA7220@apple.com>
To: Joshua Peek <josh@joshpeek.com>
On Feb 11, 2014, at 8:41 PM, Joshua Peek <josh@joshpeek.com> wrote:
> Are you proposing new mutation record type? I think that could handle
> most of the enter/leave requirements.

Not really.  I’m mostly talking about new timing at which mutation records are delivered.

Apparently we need to deliver records more “eagerly” for custom elements. 

> If MutationObservers are an open topic for extension, I'd love to see
> generic css selector support.
> 
>  observer.observe(target, { selector: 'foo' });
>  observer.observe(target, { selector: '.foo' });
> 
> That'd cover element name "enter" and "leaves" as well.

enteredView and exitedView are custom element callbacks and not elements themselves.
http://w3c.github.io/webcomponents/spec/custom/#types-of-callbacks

There has been some discussions to extend mutation observers to support better filtering.

We can probably support simple selector: http://dev.w3.org/csswg/selectors4/#simple

I don’t think we can support any arbitrary selector (e.g. descendent selector) for performance reasons since doing so requires tree traversal, and checking that condition on every DOM mutation is too expensive.

- R. Niwa
Received on Wednesday, 12 February 2014 05:32:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC