Re: [CSS4 Selectors] :matches naming bikeshed

So is the idea that eventually something like

div:matches($ p);

would (in this case) be the equivalent of:

!div p

... In case it's not obvious, I am trying to make sense of the wiki/notes vs
the draft.  It's hard to follow.  There are parts in the emails that are
future (past even level 4?) and things in the draft that don't seem to have
come from anything on the wiki or the lists..



On Fri, Jun 17, 2011 at 10:19 AM, Brian Kardell <bkardell@gmail.com> wrote:

> In reading verbiage of the draft and the comments - is that to say that
> would be valid or invalid?
>
> div:matches(p)
>
> It seems to be that it would it be effectively the same as:
>
> !div p
>
> Also - to ask the question explicitly since some rationale was given as to
> why you chose "matches" in this context... Why the "!"?  Where did that
> originate - were there some discussions? I can't find them.
>
> -Brian
>
>
>
> On Thu, Jun 16, 2011 at 11:13 PM, fantasai <fantasai.lists@inkedblade.net>wrote:
>
>> On 06/16/2011 07:58 PM, Ojan Vafai wrote:
>>
>>> I think we should rename :matches to :any.
>>>
>>> 1. :matches, doesn't make clear the "or" relationship that :any does. I
>>> could
>>>   easily interpret :matches to mean that it matches all of the selectors
>>>   instead of any one of them.
>>> 2. Two browser vendors already ship :any (vendor prefixed of course).
>>> 3. :any is less typing and fewer bytes to ship down the wire.
>>>
>>
>> I chose "matches" over "any" because
>>  1. it contrasts with :not() which is the negation of the exact same
>> functionality
>>  2. it allows expansion to a full :matches() implementation, where a full
>> :matches()
>>     implementation is that :matches() takes any selector (including those
>> with
>>     combinators); calling it :any() implies there has to be more than one
>> argument
>>     for it to be useful, which is the case now, but would not be for a
>> full version
>>
>> Basically, I think about this as
>>  :not(selector)
>>  :matches(selector)
>> where selector can include commas, as per usual (rather than as
>>  :not(selector, selector)
>>  :any(selector, selector)
>> where it can't).
>>
>> Does that make sense now or still not? :)
>>
>> ~fantasai
>>
>>
>