W3C home > Mailing lists > Public > www-style@w3.org > April 2003

Re: ID selector via attribute?

From: Michael Day <mikeday@yeslogic.com>
Date: Mon, 28 Apr 2003 22:35:19 +1000 (EST)
To: Ian Hickson <ian@hixie.ch>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <Pine.LNX.4.44.0304282221270.24862-100000@lorien.yeslogic.com>

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:


...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 # 

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

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