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

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)

    or

    ol li:all-of(aside li)

    or

    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