Matchers and pseudos
Selector matching happens rtl, but I think there's a case to be made in the case of filters this isn't exactly best.
Each part of the selector operates against an element and all of the simple selectors in CSS are, well, simple to check. Filters, however, don't have to be - the complexity of a filter is kinda N. Here's an example:
The filter above involves a lot of complexity. If the filter is subject as in the above case, this can be pretty complicated since every element is going to resolve against the inner selector only to find out that the match isn't a .
thinger. It seems to me that filters are, at least conceptually, for filtering a match, not necessarily -being- the match. Very often a filter is attached to a useful simple selector (as in the above case), it seems useful to simply flip the matcher processing since the below is conceptually identical:
This rewrite it unnatural, no one would actually write it that way (and it wouldn't be possible to write a tag match that way), but simply reordering the matchers would do it...
I'm not intimately familiar with the guts of sizzle, but it seems this is mostly possible with a simple if/else in matcherFromTokens which says 'if it's a pseudo, check the existing matcher for connected preceeding simple selectors and flip them around'.
I wrote something fairly brain dead and confirmed that this calls the filter accurately and a lot less often...
We're putting together a proposal for custom filters (predicates) in CSS and I'm thinking of suggesting that this is codified because that would greatly reduce the number of times native code would call out to JS functions...
Anyway, WDYT? Is it totally crazy, or crazy like a fox?
- .foo .thinger:_custom(.a .b:matches(.y:odd, span .x:even), .foobar)
The filter above involves a lot of complexity. If the filter is subject as in the above case, this can be pretty complicated since every element is going to resolve against the inner selector only to find out that the match isn't a .
thinger. It seems to me that filters are, at least conceptually, for filtering a match, not necessarily -being- the match. Very often a filter is attached to a useful simple selector (as in the above case), it seems useful to simply flip the matcher processing since the below is conceptually identical:
- .foo :_custom(.a .b:matches(.y:odd, span .x:even), .foobar).thinger
This rewrite it unnatural, no one would actually write it that way (and it wouldn't be possible to write a tag match that way), but simply reordering the matchers would do it...
I'm not intimately familiar with the guts of sizzle, but it seems this is mostly possible with a simple if/else in matcherFromTokens which says 'if it's a pseudo, check the existing matcher for connected preceeding simple selectors and flip them around'.
I wrote something fairly brain dead and confirmed that this calls the filter accurately and a lot less often...
We're putting together a proposal for custom filters (predicates) in CSS and I'm thinking of suggesting that this is codified because that would greatly reduce the number of times native code would call out to JS functions...
Anyway, WDYT? Is it totally crazy, or crazy like a fox?