W3C home > Mailing lists > Public > www-style@w3.org > January 2009

Re: Proposal for limited :matches pseudoclass

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 14 Jan 2009 12:42:08 -0600
Message-ID: <dd0fbad0901141042l42309370k2a802a4d2fce2fef@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style list" <www-style@w3.org>

On Wed, Jan 14, 2009 at 10:51 AM, fantasai
<fantasai.lists@inkedblade.net> wrote:
> Tab Atkins Jr. wrote:
>>
>> fantasai wrote:
>>>
>>> :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.
>>
>> ...
>> 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 { .. }
>
> Ah, my bad. I wasn't thinking. You'd actually need the bottom syntax
> in order for the top to make any sense! The examples should be
>
>  :matches(!td > input:checked)
>  h1:matches(! > input:checked)
>
> With both you can do branching.
>
>  :matches(!td > input:checked) + td { /* Select td after a td with child
> input:checked */
>
> but the simple cases don't require functional notation
>
>  !tr > td:first-child > input:checked { /* Select tr with first-child td
> with input:checked */
>
> Replace ! with $ or whatever symbol...
>
> I think functional notation with :matches is relatively confusing
> compared with picking out the subject and saying "I want to match
> *this* element in my pattern."

Reasonable people can certainly differ, but I find that breaking from
the convention that the last simple selector in the rule is the one
targetted is sufficiently confusing to be a detriment.  It's just as
reasonable to say "I want to match *this* element, but only if it has
*these* children (or siblings)", which matches up with the pseudoclass
approach rather than the ! approach.

It also makes interaction with the rest of the language complex.  For
example, pseudo-elements can only occur in the last simple selector of
a normal rule.  With this, though, pseudo-elements will have to be
allowed on the !'d selector in the middle of the rule.  (Well, we
could always say that they're still not allowed, but that's a
nonsensical restriction from an authoring standpoint.)  If they *are*
used on the !'d selector, then they have to be disallowed on the last
one for that rule.  There are further issues with pseudoelements that
must be resolved as well.

Because it's an orthogonal addition to the language (that is, it's not
a specialization or modification of existing syntax with extant
rules), what if it's used somewhere odd like :not(!td)?  We can
declare those invalid (as they should be), but there are many places
where we'd have to be specific.  By sticking to the pseudoclass syntax
we remain in familiar territory, which is a significant benefit.

There may be other areas that I can't think of at the moment, but in
general I'm against a completely novel addition to the core syntax.
The existing language constructs solve this problem perfectly well,
and do so in a way that matches with our normal intuition with how CSS
works.

~TJ
Received on Wednesday, 14 January 2009 18:42:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:15 GMT