W3C home > Mailing lists > Public > www-style@w3.org > December 2005

Re: Redo selectors instead of parent-selectors

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 21 Dec 2005 23:38:34 +1100
Message-ID: <43A94CCA.7070501@lachy.id.au>
To: Jesper Hermansen <hermandsen@vip.cybercity.dk>
CC: www-style <www-style@w3.org>

Jesper Hermansen wrote:
> A quick example.
> Say I want to show/hide an html-<img>, when hovering different links.
> I'm using a slash (/) for doing a new selector (maybe someone can think 
> of a better character).
> Markup:
> <img id="logo" src="foo/bar.png" alt="foobar" />
> <a href="http://www.google.com/">Google</a>
> <a href="/examples/">Site examples</a>
> <a href="http://w3.org/">W3</a>
> CSS:
> #logo {
>     visibility: hidden;
> }
> a[href^="http://"]:hover / #logo {
>     visibility: visible;
> }

I'm not sure I understand this properly, there's two possible 
interpretations I can think of.  The first, which I interpret from the 
sample code and which I'm sure has been discussed before, is like the 
opposite of the + and ~ sibling combinators.  This would suffer from 
many of the same problems of parent selectors.

> The selector above would first evaluate hover on the link and, if true, 
> continue to the #logo-selector, and apply the visibility-style.

The second which I gather from this description is like putting a 
condition which must evaluate to true before the actual selector will be 

   selector1 / selector2 { ... }
is equivalent to this pseudo-code algorithm.

IF selector1 matches anything
    find matches for selector2 and apply styles

This concept seems somewhat like the previously proposed :matches() 
pseudo-class (there's plenty of discussion about it in the archives), 
but it too has significant problems and we're unlikely to see it any 
time soon, if at all.  If I understand correctly, the above example 
would be equivalent to

   selector2:matches(selector1) { ... }

Lachlan Hunt
Received on Wednesday, 21 December 2005 12:45:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:22 UTC