Re: Proposal for limited :matches pseudoclass

Uhm...

the difference between "td > input:checked" and "td:matches(>
input:checked)" is the subject of the selector (the element that gets the
CSS applied), but instead of a :matches pseudoclass, if what about parent
selector (as opposite of child selector)
that is:
"td > input:checked" matches a checked input that is child of a td
"input:checked < td" matches a td that is parent of a checked input

Advantages:
- the child is always "less-than" the parent: it is easier to understand (to
me at least)
- the matched element is always the last in the selector
- we don't need a new pseudoclass (what about if we need a "matches"
pseudoclass in CSS4 for matching a RegExp? Less keywords mean forward
compatibility)

Disadvantages:
- I don't know what are counterparts of descendant and siblings selectors

Hope you'll like it.

Giovanni

2009/1/14 fantasai <fantasai.lists@inkedblade.net>

>
> Tab Atkins Jr. wrote:
>
>> This is lifted from the :has-child proposal thread, since at least one
>> person (Brad Kemper) liked the syntax, and at least one implementor (Boris
>> Zbarsky) thought it wouldn't be horrible for implementations (at least, no
>> more horrible than current child and sibling combinators).  Thought I'd give
>> it a proper write-up, since I've had reason to want it in the last week.
>>
>> /:matches pseudo-class/
>>
>> The :matches(/selector fragment/) pseudo-class represents an element that
>> has another specified element /after /it in the document tree.  The selector
>> fragment starts with either the child combinator (>) or the adjacent-sibling
>> combinator (+), optionally followed by whitespace, followed by a simple
>> selector (see Selectors Level 3 for the definition of a simple selector).
>>  This matches if an element matched by the simple selector occurs as a child
>> (if > was used) or following adjacent sibling (if + was used) of the target
>> element.  If the selector fragment is invalid or empty, the entire selector
>> is invalid.
>> Examples:
>>  td:matches(> input:checked) /* Matches any td with a checked input as a
>> direct child */
>>  h1:matches(+ ul) /* Matches any h1 which is directly followed by a <ul>
>> */
>>
>
> Going with the original idea that a full :matches() implementation
> would match any element that matches its argument selector, you'd
> need to write
>  elem:matches(* > child)
> or
>  :matches(elem > child)
> e.g.
>  td:matches(* > input:checked)
>  :matches(h1 + ul)
>
> :matches would take a normal selector rather than a fragment that
> begins with a combinator (which seems very unbalanced to me, like
> passing a mathematical function an expression that began with the
> multiplication symbol). It would just be restricted to only allow
> the > and + combinators.
>
> An alternative syntax that was proposed many years ago is to add
> the ability to change the subject of the selector with some kind
> of punctuation, e.g.
>
>  !td > input:checked { ... }
>  !h1 + ul { .. }
>
> Again, you can make the same combinator restrictions for anything
> after the !. I personally find this easier to read. A syntax like
> :matches() is only necessary if you're matching against multiple
> branches of the tree.
>
> ~fantasai
>