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

No, you’re not missing anything, in the essence. But to solve Brian’s use cases, we need a complete set of logical operators, and for now we just have a limited not and a tentatively proposed or (:matches, previously known as :any). 

 

To be really effective, a fully-featured :not() and an :and() operator would be needed. I think this was the main point of Brian, which I happen to agree to (since, for browsers, it seems really simple to implement).

 

XOR isn’t really needed and can be emulated rather easily with OR & NOT but if it’s cheap to implement, why not.

 

 

 

As for the reason of refusing :not(a b), it’s based on the (probably) valid assumption that proving the existence of something is generally faster than proving it does not exist (NP vs coNP). However, since we don’t have any P-efficient algorithm for selector matching, the worst case of traditional selectors is already matching the complexity a :not(a b) could introduce, and the sky hasn’t fallen, as far as I know ^_^

 

My bet would be to say that it’s not really a performance issue to support complex selectors in :not() but I can be wrong due to optimizations that would be impossible to make anymore and that I’m unheard of. If so, that would be interesting to know about them.

 

 

 

 


De : Lea Verou
Envoyé : ‎15‎ ‎mars‎ ‎2013 ‎00‎:‎20
À : Brian Kardell
Cc : www-style@w3.org
Objet : Re: [css-selectors] Proposal: Logical Combinators / Sets


I might be missing something here, but isn’t :anyof() essentially :matches(), :noneof() essentially :not() and :allof() essentially ...chaining of simple selectors (i.e. compound selectors)? 



Note that :not() has been extended in Selectors 4, and now supports compound selectors too [1].




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




[1]: http://www.w3.org/TR/selectors4/#negation








Lea Verou

W3C developer relations
http://w3.org/people/all#lea ✿ http://lea.verou.me ✿ @leaverou











On Mar 8, 2013, at 03:39, Brian Kardell wrote:




A recent discussion about adding Set operations on another list prompted me to discuss something to Tab which I've mulled around (even prollyfilled) in the past and think it's worth proposing...




CSS selectors operate on _sets_ of elements, but until  recently (:matches/:not) we've had nothing in the way of logical selectors or any language constructs that hinted at set oriented language.   This seems a shame to me as sets and logic gates are some of the most powerful concepts in CS.  The relationship feels natural to me.





This proposal would require us to get complex selectors inside, but essentially I am proposing some logical combinators like 
:anyof, :allof, :oneof, :noneof to act as predicates which allow some very rich selection.  Examples/more details in my blog post:




http://briankardell.wordpress.com/2013/03/07/logical-psuedo-selectors-a-proposal/





-- 
Brian Kardell :: @briankardell :: hitchjs.com