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

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

From: Brian Kardell <bkardell@gmail.com>
Date: Wed, 20 Mar 2013 19:09:58 -0400
Message-ID: <CADC=+jfRJhboJY+hwhFhR283MPE7yHTRdruBO=dLtjskLUcSkA@mail.gmail.com>
To: Simon Sapin <simon.sapin@exyr.org>
Cc: "www-style@w3.org" <www-style@w3.org>
On Wed, Mar 20, 2013 at 6:28 PM, Simon Sapin <simon.sapin@exyr.org> 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)

I noted that in the minutes there didn't seem to be much beyond the
name and a quick mention of the larger logical proposal... Was there
any more?  The reason I ask is that I think if affects the
conversation a little.  The above example looks mostly like the stuff
we are discussing for Selectors 4 and the point of asking for
consideration was the long view in which logicals would want to have
complex selectors - which I think frames the conversation better...
Just curious.

> 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)

I'm aware of the history and the cases for the existing proposals.  At
one point, I think they made more sense because of what it was trying
to cover.  Still, I kind of disagree that

    ol li:any-of(aside li)


    ol li:all-of(aside li)


    ol li:one-of(aside li)

(or whatever we'd like to call logical stuff I described) is
inherently significantly less grokable somehow than :matches.  I'm a
lot more interested in rich set capability than names in the end - but
I do feel like there is a case to be made for those using a consistent
logical/set sort of language..

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

Is that different from in my proposal?  Explain where - I think I
might be misunderstanding something...

> Thoughts?
> --
> Simon Sapin

Brian Kardell :: @briankardell :: hitchjs.com
Received on Wednesday, 20 March 2013 23:10:28 UTC

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