Re: Surface JavaScript APIs for selector match changes

On Mon, Apr 7, 2014 at 6:04 PM, Joshua Peek <josh@joshpeek.com> wrote:
> This post is a follow up to the CSS.Next discussion at the  Extensible
> Web Summit.
>
> Element#matches can test the current state of a selector against an
> element, but theres no unified way to know when a selector will be
> matched or unmatched in the future.
>
> Detecting selector changes are typically used by CSS polyfills. And
> even application code usually needs to enable or disable behavior
> after as the page dynamically changes. Typically developers only check
> selectors once on DOMContentLoaded which is error prone.
>
>
> One possible API might fit into Tab's old EventStream idea
> (http://www.xanthir.com/b4PV0).
>
>     el.watchMatches('.foo').then(function(matches) {
>       if (matches)
>         console.log(el, 'now matches .foo');
>       else
>         console.log(el, 'no longer matches .foo');
>     });

I recommend strongly against doing anything with EvenStreams yet.
Just rely on the tried-and-true method of using events or something.
^_^

> Although, I think I would find a more MutationObserver like API more
> useful. Since it could pick up new elements added to the tree that
> match the selector.
>
>     var observer = new SelectorObserver(function(record) {
>       console.log(record.target, 'now matches', record.selector);
>     });
>     observer.observe(document, {selector: '.foo'});

I've been thinking we should add a Selector interface anyway.  What
about an API like:

var sel = new Selector(".foo", document)
sel.watch(function(record){...})

Or something similar.  Dunno whether I'd want to use events or
callbacks, and whether it should fire once per element (passing that
element to the callback) or once per set change (passing the matched
set to the callback).

> MutationObservers do provide low level plumbing for node and attribute
> changes. Then there are UI events like focus and change. But theres a
> set of current pseudo classes that depend on element on property state
> and do not have reliable change events, like :checked, :indeterminate,
> :enabled and :disabled. Trying to implement this efficiently in JS
> gets tricky as well. Other hacks piggy back on the animationstart
> event to attempt to leverage the efficiently of the browsers css
> matcher (http://www.backalleycoder.com/2012/04/25/i-want-a-damnodeinserted/).
>
>
> I feel like exposing some sort of API like this would help explain the
> magic behind CSS rule matching and style application today.

I love the animationStart hack, it's brilliant. ^_^

But yes, having something for this would be ideal.

~TJ

Received on Wednesday, 9 April 2014 00:52:19 UTC