RE: XPath as CSS-selectors?

Boris Zbarsky wrote:

>>> CSS Selectors are currently carefully designed for
>>> performance. XPath is not.
>> 
>> Well, this is an implementation issue, and not caused by
>> the design tiself.. Or?
> 
> It's caused by the design, though can be somewhat mitigated
> by implementation.

Both CSS Selectors and XPath can be implemented in a bad way,
and I think if they are implemented good, with fast underlying
algorithms, the difference in speed between the two will be
unremarkable but in the slowest of the slowest clients (like
PDA's which most likely won't have full functionality in any
way, anyhow).

> As of CSS2, a node can only affect the styling of its
> descendants.

As you mention yourself, this isn't quite true. :)

> 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? :)

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

> that relies on XPath selectors.

If you rely script code on XPath selectors, it's your problem
that it works slow. As it is your problem that your for-loop
goes slow because you do insane calculations in it which you
easilly could do outside. For example.

> one can optimize this in some ways, eg by keeping around flags
> that say whether any of the currently loaded sheets contains a
> "bad" selector

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.

> So pages that do _not_ use such selectors could maybe still be
> reasonably fast... but pages that do use them would have
> abysmally slow response to any dynamic changes

Therefore it's not recommended to use dynamic scripting in
conjunction with "bad selectors", 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.

> Of course it is precisely having such selectors that is one of
> the main advantages of XPath over CSS Selectors as stated earlier
> in this thread, so eschewing their use makes XPath far less
> desirable...

Yes. Though it would be nice to have the imho neater and more
precise XPath syntax available, I think that if we whittle on what
we implement from the XPath spec, it's no use implementing it at
all. All or nothing.

>> The more, the merrier. Right?
> 
> Well, not from a UA implementor standpoint... ;)

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.

> Could you please point me to the UA you used to evaluate how well it
> works?  I would very much like to try out XForms.

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

-- 
Asbjørn Ulsberg           -=|=-          X-No-Archive: No
"He's a loathsome offensive brute, yet I can't look away"

Received on Friday, 20 June 2003 06:14:04 UTC