Re: Selector for parent/predecessor?

On 8/20/06, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> Giuseppe Bilotta wrote:
> > in my limited HTML authoring experience I've come across a few
> > situations in which I would have liked to have the possibility to
> > change the style of an element depending on whether it was the
> > /parent/ (or more in general an ancestor) of another element, or to
> > select an element because it was /followed/ by a particular sibling.
>
> This has been requested many times before.  Search the archives for
> parent selectors and the :matches() proposal.  IIRC, such proposals get
> rejected because it doesn't fit the CSS processing model and also
> performance issues.

Ok, sorry for acting like a total newbie and forgetting to check the
archives. I've seen the :matches() proposal and I find it to be an
excellent proposal. It definitely gets my vote.

I spent the last hour or so browsing through the archives, but I
haven't really seen a well-described argument against.

The performance issue is, IMHO, a totally moot point, considering the
alternatives (some JavaScript that does this, or even worse
hand-coding ad-hoc classes). UA-coding this stuff has much more room
for optimization than any alternative.

I don't get the "doesn't fit the CSS processing model" at all, not for
:matches (I could see why the argument was valid for the :subject
alternative, for example)

> > input[type="radio"] < form:not(input[type="radio"]:checked < form) { ... }
>
> :not() can only contain a simple selector.  In other words, it cannot
> contain any combinators.

This limitation seems rather arbitrary to me. And judging by the
answers from others, it even makes it more complex to parse ... why
shouldn't any kind of CSS selector be allowed in :not ?

--
Giuseppe "Oblomov" Bilotta

Received on Monday, 21 August 2006 06:21:11 UTC