W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: Surface JavaScript APIs for selector match changes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 9 Apr 2014 09:25:04 -0700
Message-ID: <CAAWBYDDYNkU2Rkt-w4fFFLeEsh=-goai+TfNRgP4gA5OQ-e3hg@mail.gmail.com>
To: Joshua Peek <josh@joshpeek.com>
Cc: www-style list <www-style@w3.org>
On Tue, Apr 8, 2014 at 9:28 PM, Joshua Peek <josh@joshpeek.com> wrote:
> On Tue, Apr 8, 2014 at 7:51 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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).
>
> That sounds wonderful too.
>
> Maybe it would expose the reverse of the Element match and query? e.g.
> sel.matches(element) and sel.queryAll(container).

Yes, that was the original intention.  I expect to add all the
selector-using methods to Selector, with identical behavior, and
slightly different semantics, such that using the Selector version
over the Element version is similar to using a compiled regex vs an
uncompiled one - the Selector version takes a little more time to set
up because the UA is optimizing it, but runs faster afterwards.

> Heres another API idea.
>
>     var sel = new Selector(".foo", document)
>     sel.watch(function(el) {
>       // matched a .foo, lets add an event handler to it
>       el.addEventListener('click', onClick);
>       return function() {
>         // .foo was removed from our element instance, cleanup
>         // its event handler to disable the behavior.
>         el.removeEventListener('click', onClick);
>       };
>     });

Hm.  Here, the callback gets called on each element as it matches, and
then you're expected to return a callback for calling when it stops
matching?  Interesting.

> Also related to the Selector interface idea, I've worked on a
> "selector set" concept that was implemented mainly for performance. It
> models the CSS rule matching API kinda nicely. Though, it doesn't
> cover this "watching" concept.
>
>     var styles = new SelectorSet();
>     styles.add('p', {
>       fontSize: '12px',
>       color: 'red'
>     });
>     styles.add('p.item', {
>       background: 'white'
>     });
>
>     // apply matching styles to element
>     styles.matches(el).forEach(function(rule) {
>       for (name in rule.data)
>         el.style[name] = rule.data[name];
>     });
>
> https://github.com/josh/selector-set

Hm, I've read over the github README, and I'm not sure I see what
use-cases this is addressing.  Could you help me understand what it's
useful for?

~TJ
Received on Wednesday, 9 April 2014 16:25:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:21 UTC