Re: Surface JavaScript APIs for selector match changes

On Wed, Apr 9, 2014 at 11:25 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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.

Rad. Seems like that would fit right into WebKit's selector
compilation step -
https://www.webkit.org/blog/3271/webkit-css-selector-jit-compiler/

Are you working on the draft spec for this?


> 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.

Exactly. Constructing the "stop matching" hook inside gives you an
easy way to track state between setup and teardown of behaviors. It
also ensures your "stop" callback is always ran before the next "start
match" again.


> 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?

Sorry, the README still feels like its lacking context.

Element#matches (and even QSA) give you no information on which
selectors matched a selector list. el.matches("h1, h2") only tells you
the el was a h1 or a h2. This makes selector lists not that useful for
batch testing selectors for efficiently. You pretty much have to test
selectors one by one. And if you're trying to build a CSS matching
engine, that kinda of thing doesn't scale to testing hundreds of
selectors.

I recently wrote a post about using it to speed up event delegation
matching in jQuery
(https://github.com/blog/1756-optimizing-large-selector-sets).

Though, this set abstraction is more low level than I think
applications actually need. If "selector watching" was implemented, I
wouldn't really need it.

Received on Wednesday, 9 April 2014 18:09:56 UTC