RE: Selector for parent/predecessor?

Well, if no grouping is implied, it would indeed select all paragraphs
except the first, of divs that contain blockquotes. But the point is
that without delimeters it's an ambiguous notation at best, take:

div < (blockquote p) ~ p 

This would select paragraphs following divs that contain blockquote
childs with 1 or more paragraph descendants, and:

div < (blockqoute p ~ p) 

... would select divs with blockqoute childs that contain 2 or more
paragraph descendants. 

Such grouping is (in my opinion) essential to the nature of the proposed
selector functionality. Better yet, there's hardly any difference left
in the notation between :matches() and < (), except that < implies
childs, and :matches() doesn't directly imply any related selector...
which is why I favor the latter.

It makes perfect sense. I honestly don't mean to offend anyone, but I'm
actaully a bit disappointed that this discussion is smothered with
off-topic debates on who guards the CSS temple, and the apparently
accepted fact that implementors ultimately decide what makes it to the
spec, and what doesn't. 

Obviously any technical argument should be taken into account when
considering functionality, but mere "difficulty" is no show stopper
argument. Inefficiency is, but it has already been pointed out that a
predecessor selector doesn't have to be inefficient at all.

Lack of both existing and supported selectors forces us to resort to
inconceivably slower javascript based selector methods to select the
elements we wish to style. If anything, the sheer amount of such scripts
out there is proof not only of the lack of CSS support by various
browsers, but also of desired features (and of course it's proof of the
awesome community around front-end tech, the rise of CSS over he last
decade or so is truly amazing).


:)


Peter.


-----Oorspronkelijk bericht-----
Van: Joao Eiras [mailto:joao.eiras@gmail.com] 
Verzonden: Thursday, August 24, 2006 3:33 AM
Aan: Peter Nederlof
Onderwerp: Re: Selector for parent/predecessor?

Peter Nederlof <peter.nederlof@lostboys.nl> wrote:

> A < selector would obviously be flawed. Selectors will become
unreadable
> and unparsable; There's no telling what this would return:
> div < blockquote p ~ p { }

That selector returns, for each group of siblings, all paragraphs except

the 1st :) But that requires a O(n*n) resolution time to match it
against  
the dom, unless the parser implements some heuristic to optimize it.

I've found many situations where a parent selector would make sense and
be  
extremely necessary, not only when building my one web application, but

too when designing my custom user-agent style sheet for some 3rd party  
website.

And I agree with Peter: the inefficiency or misuse of browser features  
isn't a valid argument to hold back the evolution of standards.

Received on Thursday, 24 August 2006 08:56:17 UTC