Re: Selector for parent/predecessor?

Peter Nederlof wrote:
> 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

Indeed.  We should leave the discussion focused on technical issues.  I 
find it interesting that my one mail that discussed such issues got only 
one response (from Allan, outlining the style reresolution setup in 
khtml in very broad strokes).

> and the apparently
> accepted fact that implementors ultimately decide what makes it to the
> spec, and what doesn't. 

This is an accepted fact for two reasons.  First, the spec exists so 
that implementors will implement it.  If they don't, it's pointles. 
Second (and a consequence of the first point), every part of the spec 
needs to have two interoperable implementations to make it out of CR. 
If the implementors don't plan to implement it, why bother wasting time 
specifying something that won't end up in the spec anyway?

> Obviously any technical argument should be taken into account when
> considering functionality, but mere "difficulty" is no show stopper
> argument.

That depends on the timeframes involved, of course.  If something is 
difficult and you want your spec to go to REC soon, then the difficulty 
needs to be considered for sure.

> Inefficiency is, but it has already been pointed out that a
> predecessor selector doesn't have to be inefficient at all.

No.  It's been pointed out that simple cases of the predecessor selector 
can be handled efficiently in time if you accept inefficiency in memory 
usage.  Then the implementor who pointed this out said that he's not in 
favor of a general predecessor selector, if you not.  This is not the 
same as your statement.

> Lack of both existing and supported selectors 

There's a big difference between those two, for what it's worth.  Please 
don't lump them together.

> forces us to resort to inconceivably slower javascript based selector methods to select the
> elements we wish to style.

It's pretty easy to create javascript methods that are a lot faster than 
an all-purpose implementation of the ancestor/predecessor selector, if 
you have knowledge of what things will and will not change in your document.

-Boris

Received on Thursday, 24 August 2006 17:27:13 UTC