W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Re: [selectors4][naming] Renaming :matches() (was: Proposal: Logical Combinators / Sets)

From: Lea Verou <lea@w3.org>
Date: Sun, 24 Mar 2013 21:38:10 +0200
Cc: www-style@w3.org
Message-Id: <F545E2C2-2226-4A0E-9708-5F64B966E3DD@w3.org>
To: Simon Sapin <simon.sapin@exyr.org>
On Mar 21, 2013, at 00:28, Simon Sapin wrote:

> Le 15/03/2013 14:57, Brian Kardell a ťcrit :
>> On Mar 15, 2013 9:14 AM, "Lea Verou" <lea@w3.org> wrote:
>>> 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().
>> Excellent  :-) I think it makes more sense in historical perspective
>> given the use cases they were hoping to solve and the evolution of
>> ideas that were being tossed around.  At this point though, any or
>> any-of definitely seems more sensible.
> We discussed this on the conf call today. :any() is great when there are multiple arguments:
>  some > long + combinator ~ chain:any(.foo, .bar)
> But one counter-argument that convinced me is that it doesnít make any sense with a single argument. This can be useful when that selector contains combinators:
>  ol li:matches(aside li)
> A good way to think of this is that :matches() does *not* take a comma-separated list of arguments, but its single argument is a comma-separated list of selectors. The pseudo-class is true for elements that *match* the inner selector list. The commas there have the same meaning as at the top level.
Yup, I was in that call too :P

Thatís a good argument. Indeed, :any() doesnít make sense if you donít have a selector list.

Has the idea of :and() been discussed? For example `ol li:and(aside li)`
Canít see it in this thread. It makes sense for every case I can think of, and is 3 characters instead of 7, just like :any() (of course, it doesnít have the benefit of existing implementations, like :any() did).
Received on Sunday, 24 March 2013 19:38:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:27 UTC