Re: ID selector via attribute?

Hi Ian,

> It gets a bit confusing with, e.g.:
> 
>    h1:has(+ p) /* an h1 that has a p after it */

Yes, in fact I'm tempted to only let it contain a single simple selector,
similar to :not(), that applies to its descendants. At least to begin
with, anyway.

> How is XPath easier to use or understand than the equivalent CSS with
> :matches()? (You could just be more familiar with XPath than CSS.) Could
> you show the XPath equivalents for the examples at the bottom of:?
> 
>    http://lists.w3.org/Archives/Public/www-style/2002May/0037.html

I suppose I feel that once you need selectors that are as general as
XPaths, you might be overdoing it. But I'll give it a try:

  CSS:    village garden:has(plant > flea)
  XPath:  village//garden[.//plant/flea]

  CSS:    plant:not(:has(> flea)):has(+ plant > flea)
  XPath:  plant[not(flea)][following-sibling::plant/flea]

  CSS:    :root:matches(antiflea, # antiflea) flea
  XPath:  flea[//antiflea]

Some are longer, some are shorter. I like to think that CSS selectors hit 
the 80:20 point for most styling requirements though.

> For example, the current definition makes:
> 
>    a:matches(b)
> 
> ...useless. Nothing that simple should be that useless IMHO. :-)

Not necessarily, consider this:

    a:not(a)

...equally useless! :) In fact I find it easier to understand :matches by 
thinking of it as a dual of :not, which of course is unnecessary (as 
positive selectors can be concatenated already) unless you need the # 
reference.

Perhaps :has(foo) could be considered for inclusion in a future spec,
where foo is any simple selector? That would be a simple base to build on,
without having to sort out # references all at once.

Michael Day

YesLogic Pty. Ltd.

Received on Monday, 28 April 2003 07:16:08 UTC