Re: XPath as CSS-selectors?

Asbjørn Ulsberg wrote:

> Both CSS Selectors and XPath can be implemented in a bad way,
> and I think if they are implemented good, with fast underlying
> algorithms

Please feel free to suggest these magic algorithms...

>>On the other hand, with XPath any element can affect the
>>styling of any other element, as has already been mentioned.
> 
> Yes. Isn't it nice? :)

It's a design tradeoff.  It has some advantages; it has some severe 
disadvantages.

>>Consider a web page using a 'javascript ticker'
> 
> I'd rather not, but for the sake of argument; ok. (I hate
> tickers and most of the rotten scripts that exists out there).

Very well; consider a simple svg-based visualization app that rotates 
the object being visualized.  Say it's a rabbit, for concreteness.

> If you rely script code on XPath selectors, it's your problem
> that it works slow.

Well, the XPath selectors may not even touch the part of the page that 
uses the script...  I'm rotating my svg bunny with script, while at the 
same time the control panel for the app is styled using XPath selectors. 
  The UA may attempt to detect this situation, but all the style 
resolution algorithms I've been able to think of so far (in oh, 7 or 8 
months of thinking about style resolution on and off) have severe 
pathological cases that would be triggered by such code.  That's not 
saying much -- I'm a poor algorithm designer.  Those abovementioned 
algorithms that allow fast XPath matching or fast decisions as to when 
matching is not needed would be quite handy here.

The worst part is that any sufficiently sophisticated algorithm for 
deciding not to reresolve style takes up far too much time in the common 
case, which, with today's web, is that the inline style of an object is 
being changed and the style on it and its descendants needs to be 
reresolved.

> That would of course be nice, but I don't really think it's
> necessary. Bat code is bad code, and bad programmers are bad
> programmers, whatever the language or environment gives access
> to or put constraints upon.

Unfortunately for this point of view, one of the goals of CSS is to be 
usable by people who are bad programmers; indeed by people who are not 
programmers at all.

> but stupid people will do stupid
> stuff no matter what you tell them and how you say it. Stupid web
> developers don't even read specifications, so it's a lost match
> anyhow.

I'm not sure a holier-than-the-people-making-use-of-this-spec attitude 
is the right one to adopt when writing a spec... (not that W3C WGs are 
not guilty of it at times... ;) )

> Yes. Though it would be nice to have the imho neater and more
> precise XPath syntax available

As stated, the niceness of the XPath syntax is very subjective.

> No, of course not. But XPath parsers exist already, so I believe
> it's not that big of a task to implement. I might of course be
> wrong, though.

Integrating the XPath parsers and CSS parsers, while handling forward 
compatibility, would be somewhat nontrivial, yes....

Just to clarify, I'm not against adding XPath-like functionality to CSS, 
as long as everyone involved is aware of the potential pitfalls.  I 
think that waving said pitfalls away with unsubstantiated claims that 
things "should be easy" if somehow "done right" is not exactly the right 
approach.

> http://www.x-smiles.org/

Thank you.  I'll have to check it out.

-Boris

Received on Friday, 20 June 2003 06:43:35 UTC