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

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