Re: ID selector via attribute?

On Mon, 28 Apr 2003, Michael Day wrote:
>> 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.

That makes some sense, I guess.

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

I have to say, I don't see much improvement over CSS. :-)

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

Selectors are not likely to be changed for a while, but certainly I have
every intention of proposing :has() and its variants when it is.

Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.                         `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 28 April 2003 14:49:54 UTC