Re: [css-selectors] Proposal: Logical Combinators / Sets

FWIW, I agree that :any() is a much better name than :matches(). I was always baffled by the WG’s decision to name it :matches, despite the existing implementations, straightforwardness and brevity of :any().
On Mar 15, 2013, at 03:57, Brian Kardell wrote:

> 
> On Thu, Mar 14, 2013 at 7:19 PM, Lea Verou <lea@w3.org> wrote:
> I might be missing something here,
> 
> More likely my fault because there is both a more general "I propose we be able to discuss elements with some fairly logical/set language" and then some pretty specific details for a single possible answer to that question (the thing I have prollyfilled and described in more detail).
> 
>  
> but isn’t :anyof() essentially :matches(), :noneof() essentially :not() and :allof() essentially ...chaining of simple selectors (i.e. compound selectors)? 
> 
> I think I noted in the proposal that ":anyof" might just be what is "currently" known as ":matches" and ":noneof" might just be ":not".   
> 
> /me checks... 
> Yes I did, but I suppose that could use some explanation about why they may or may not be.  There is some hand-waving on names :)   In the more general sense, they very well might be - but since they don't have complex selectors or a full description of what those would mean, it's hard to say if that would match my more specific implementation proposal or whether this is a wholly new proposal.  Does that make any sense?  Let me give you an example:
> 
> .product:matches(.blue .windows, .red .doors)
> 
> While there have been discussions, I don't know that it is specified (and definitely not implemented or far along in the process) how complex selectors work.  Some form of matches/not have been discussed since at least 1999 on the list[a] (most examples on the list in 2000 had complex selectors!) and I've read so many that I don't know what the thinking is (or if there even is one) on what exactly that would mean... For example:
> 
> which does that the equivalent of:
>     a)  .product .blue .windows,  .product .red .doors
>     b)  .blue  .product.windows,  .red  .product.doors
>     c) .product.blue  .windows,  .product.red .doors
> 
> 
> What would combinators mean in it? Could they start with a combinator, and what would that mean, etc... 
> 
> I have suggested in my implementation that the answer to this question is b - each selector in the group matches as per normal and the results of a .matchesSelector test on any of them could be true or false.   This not only side-steps a lot of those questions (because they are all independent) but it seems easily optimizable, able to follow already written code paths for most of it and cause no potential "we can't know that yet" sorts of problems and for some cases allows you to construct selectors that can't be currently expressed...
> 
> Also, I'm not sure that the name "matches" is finalized.  I kinda hate it and I know I'm not the only one, at least Mozilla's was called ":-moz-any" and I think that webkit copied that.  I've seen some proposals to change it to :any - so there's that bike shed thing too :)
> 
> 
> 
> 
> Note that :not() has been extended in Selectors 4, and now supports compound selectors too [1].
> 
> 
> But not complex selectors which, as I noted in the post, are required to make this do anything worthwhile and (at least to me) seem to be kind of a non-problem with my specific answer to that above.  (Someone will correct me I'm sure :))
> 
>  
> The only use cases I see that this covers are:
> 
> 1. XOR, by :oneof()
> 2. Negation of complex selectors
> 3. Disjunction of complex selectors (as part of a larger selector, otherwise it can be done already with commas)
> 4. Intersection of complex selectors 
> 
> I’m not sure if #1 is really needed, and the example in your blog post isn’t exactly a real use case.
> 
> If you do 2, 3, 4 it is only a little bit more to add it for completeness of the concept and surely you can think of uses :)  I'm not sure why the example on my post isn't real enough though, we can't do it that way today so we don't.
> 
>  
> #2 and #3 could be useful, and could be solved by allowing complex selectors in :not() and :matches(), no need for new pseudo-classes. However, I’d bet there was a good reason that we didn’t allow this, since it’s obvious from the spec text that it has been considered. #4 could be useful as well, but I’m pretty sure the reasons preventing #2 and #3 would apply to it too.
>  
> I think I addressed those above, right?
>  
> 
> [a] http://lists.w3.org/Archives/Public/www-style/1999Nov/0241.htm
> 
> 
> Brian Kardell :: @briankardell :: hitchjs.com