RE: XPath as CSS-selectors?

Boris Zbarsky wrote:

>> I think if they are implemented good, with fast underlying
>> algorithms
> 
> Please feel free to suggest these magic algorithms...

There are already algorithms for both, but I don't know how
good these are, and how well they can be combined. I'm not an
UA-developer (thank god! :).

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

I don't think the disadvantages are more severe than the
advantages, but it's all in the eye of the beholder, of course.

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

I understand what you say and your point, and I have no immidiate
solution for it. As I wrote to Ian; I haven't thought about this
very much. It's just a hunch.

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

True. But the script is still dependant (in some way) on the
selectors. Therefore, one shouldn't be using XPath in conjunction
with script; instead one should use CSS Selectors.

This can be restricted by the smart "flags" you mentioned.

> I'm rotating my svg bunny with script, while at the same time
> the control panel for the app is styled using XPath selectors.

If the control panel isn't changed (e.g. no x/y values in it are
updated while the rabbit rotates), then will it need to re-evaluate
the 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 
> [...] have severe pathological cases that would be triggered
> by such code.

I understand. I just have to admit that I don't know very much
about what lies beneath the neat API of CSS, and what magic is
being done in each browser.

> Those abovementioned algorithms that allow fast XPath matching or
> fast decisions as to when matching is not needed would be quite
> handy here.

Yes. I haven't got these in my pocket, but I'm almost confident
that someone could cook some brilliant stuff together. *Almost*
that is. I really have no idea.

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

Good point. Therefore XPath won't replace CSS Selectors, but
exist as an alternative to more advanced developers.

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

I guess you're right. I just get extremely frustrated over bad
(web) programming sometimes. Oh how I wish there could be some
decent WYSIWYG editors which could produce valid (X)HTML, and
didn't allow the author to do things The Wrong Way. Well,
realitycheck; it won't happen. Ever.

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

Well, not just. XPath does some stuff in a clearer and more
understandable way than CSS Selectors does. This isn't just my
opinion, as I've seen this with many other web developers I
currently work and have worked with.

For instance, the use of '/' and nothing else as a node-separator,
is brilliant and easy to understand. Most people have a relation
to URLs and folders in their OS, so they get the point pretty
quick. The '//' axis is understood even without knowing what it
does, because it uses the same syntax as the node-separator.

Also, as Christian Wolfgang Hujer mentions, the use of '@' as 
>> 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 09:26:16 UTC