RE: Selector for parent/predecessor?

In my opinion you're sending out the wrong message if the argument for
not implementing (or considering) a spec, is that it may be difficult to
implement, and assumed inefficient at best when implemented. The less
there is to support, the faster the system. The fastest implementation
therefore supports next to nothing ... 

Holding back CSS for efficiency reasons based on the abuse of tables is
equally strange. Those who use markup for layout purposes are mostly
oblivious of CSS; they can't abuse a selector which (as far as they're
concerned) doesn't exist. CSS users shouldn't become the victim of that,
should they?
 
A < selector would obviously be flawed. Selectors will become unreadable
and unparsable; There's no telling what this would return:

div < blockquote p ~ p { }

However, the legendary :matches() makes perfect sense, and doesn't
violate selector parsing rules:

div:matches(blockquote p ~ p) { }

(it may lack purpose, but it makes sense)

If the question is whether we need a selector that enables us to select
elements based nested or following nodes in the dom, I'd say yes. It
complements the child > and sibling selectors + and ~ by doing what they
do in reverse direction.

As an everyday user of CSS I actually can't fathom why it never made it
to a spec. Now, if only everything in the specs were supported! ;)


Peter



-----Oorspronkelijk bericht-----
Van: www-style-request@w3.org [mailto:www-style-request@w3.org] Namens
David Hyatt
Verzonden: Wednesday, August 23, 2006 12:30 AM
Aan: Allan Sandfeld Jensen
CC: www-style@w3.org
Onderwerp: Re: Selector for parent/predecessor?


Yeah, exactly.

dave

On Aug 22, 2006, at 3:16 PM, Allan Sandfeld Jensen wrote:

>
> The issue is more that some possible selectors would never be  
> efficient.
>
> `Allan
>

Received on Wednesday, 23 August 2006 09:24:01 UTC