Re: Proposal for limited :matches pseudoclass

On Tue, Jan 13, 2009 at 7:50 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> Tab Atkins Jr. wrote:
>> 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.

Heh, my functional programming background shows through.  It doesn't
seem at all odd to me to pass curried functions around as arguments.
^_^

Using a full selector doesn't add anything to the proposal, though,
and using a * specifically seems confusing (it only ever applies to
the element being matched, but *seems* like it could have wider
meaning).  If we were going to require that, we might as well do it
properly so that the syntax can be generalized later if we decide it's
workable.  An old proposal used "#" as a placeholder for "the element
this pseudoclass is applying to".  Theoretically the # could be placed
anywhere in the selector, but for the purpose of this proposal it
would have to go in the front.  Another pseudoclass that I believe I
proposed (though I was certainly not the first) could be simulated
with this by placing the # at the end.

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

Yup, read the thread where that came up, but I'm with Ian in not
liking it very much.  It changes too many things about CSS that I
think are relatively prime, and allows you to write too many invalid
selectors.  As well, the loss of the ability to match against multiple
branches is something we shouldn't take lightly, I think.

~TJ

Received on Wednesday, 14 January 2009 16:04:18 UTC