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

Re: :matched() proposal (Was: target-attr() and /reference combinator/ proposals)

From: Sjoerd Visscher <sjoerd@heeten.nl>
Date: Fri, 28 Jan 2000 13:49:59 +0100
Message-ID: <001501bf698e$34e727e0$1400000a@beneden>
To: "www-style" <www-style@w3.org>
> > But I think :matched is not a good idea. Instead I'd like to propose
> > a 'this' indicator inside :matches(), f.e. #
> The original proposal, which morphed into the current :matches()/
> :matched() pair, did in fact do this (or something very similar).
> It was considered too complicated. I would (now) tend to agree.
> (Note that on a less important note, the "#" character could not be
> used due to it being used for the id selector.)
I thought this wouldn't matter, because ID's cannot be empty.
But another character is fine to me, I'll keep using # until someone
comes up with a better idea.

> > And :matches() should also support multiple selectors:
> >    B:matches(A # C,C # A)
> > is equivalent to
> >    A B:selected C,C B:selected A
> This looks like it is getting a little complicated...
Is it?

People, like me, who don't speak English natively might disagree.

take f.e.:



   B:matches(A #)
   B:matches(# A)

The first 2 are unclear about which relationship is meant, the second 2 are
The easy thing about :matches with a this indicator (even with comma's) is
one can simple replace the this indicator with the element to which
applies to, and you have an ordinairy selector.

> Let's not worry about extending :matches() to accept comma separated
> lists before CSS4, shall we? Currently I am proposing that the _only_
> :matches() functionality that should be added to CSS3 is that which
> can also be done using the :selected aberration (i.e., only allow
> :matches() at the end of a selector).
> Then in CSS4 we can loosen that, and allow :matches() everywhere, then
> maybe in CSS5 we can introduce :matched().
I'd like to discuss the perfect functionality. The pace at which this is
added to CSS is another issue. Choosing simple functionality first, might
obstruct later advanced functionality needs.

> The advantage of the current proposal is that the selector inside
> :matches() and :matched() is just a straight forward selector -- no
> new syntax. If you introduced new syntaxes, like '#' to mean "this",
> etc..., then you start really complicating the life of the
> implementors... And also probably start confusing the authors!

I'm as much confused about matches and matched as one could be confused
by a 'this'.

> > Should there be negative pseudo-elements?
> What would that mean??? The concept of a negative pseudo-element is
> nonsensical, isn't it?
It is. Although 'negative' is not the right word, better would be

::not-first-line is just as usefull as :not-first-child

Only negative :before and :after are useless.

Sjoerd Visscher
Received on Friday, 28 January 2000 07:49:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:52 UTC