Re: Proposal for limited :matches pseudoclass

On Wed, Jan 14, 2009 at 1:57 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> Tab Atkins Jr. wrote:
>>
>> It also makes interaction with the rest of the language complex.
>
> I don't think so.

Well, I've provided some examples.  I'll get into it a little more further down.

>> 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.
>
> All you have to say is that pseudo-elements are only allowed on the
> subject of the selector. Period. Whether that subject is explicitly
> noted with ! or whether it's implied by being the last part of a
> selector without !, it is not necessary to specify.

That solves *one* problem with pseudoelements, but definitely not all.
 What about "!p::first-line a"?  In a perfect world, this would
hopefully match a paragraph with a link on the first line.  In
reality, though, this presents exactly the same problems that
"p::first-line a" (that is, the same selector, just with a normal
subject), which is *not* allowed in CSS.

There is a way around this, namely, specifying that pseudo-elements
are *not* used for matching, but are merely targeted afterward (in the
selector I gave, it would mean matching the ::first-line of any <p>
which contains an <a>).  This adds one more unit of complexity to the
selector, though, in that you have to ignore the pseudoelement while
reading the selector, and mentally add it back in once you've
determined what real element is being targeted.

Considering that many authors have trouble distinguishing
pseudoelements from pseudoclasses in normal situations, this also adds
to the learning difficulty.

>> 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.
>
> :not() should be the opposite of :matches() imho. I.e. :matches()
> means "matches the selector given as an argument" and :not() means
> "does not match the selector given as an argument". This is entirely
> consistent with the way :not() is defined today, it is merely an
> extension of it. And this makes :matches() align with that definition.
>
> Another use case for :matches() defined as above, and one which I
> would expect to see sooner since it's merely syntactic sugar, is this:
>
>  tr.special :matches(td, th) { styling for cell }
>
>  .toc:matches(ol, ul) > li > :matches(ol, ul) { font-size: smaller; }

That proposal is actually completely separate from what the rest of
this thread is about.  You *can* implement it using a *general* form
of the :matches() syntax, but I think they're sufficiently separate in
uses that it is actually *harmful* to authors to unify their
implementations.  I know that I proposed this to the list once (again,
I definitely wasn't the first), but I used the name :any().

Plus, as you noted, it does *not* incur a performance hit like the
various :matches() proposals do (or at least, not of the same
magnitude, and not for the same reasons), and so is likely to be
implementable much more easily.  (If it's not clear why this is merely
sugar, and not a real power, anytime you would use this operation you
could instead just write several (possibly *many*) selectors.  Frex,
rather than "tr.special :any(td, th)" you could write "tr.special td,
tr.special th" and achieve an identical effect, which is precisely
what is currently done by authors.)

~TJ

Received on Wednesday, 14 January 2009 20:32:20 UTC