Re: XPath as CSS-selectors?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Asbjørn,
Dear list members,

On Friday 20 June 2003 11:03, Asbjørn Ulsberg wrote:
> Herr Christian Wolfgang Hujer wrote:
> > as Ian already said, CSS selectors were before XPath.
> SGML were before XML. What's your point? :)
Oh, my point just was padding some CSS fans' toes before stepping on the 
selector ones... ;-)

> > As already stated, XPath is missing some of CSS's selectors.
> Therefore it must be possible to combine them.
As you already showed, like e.g.
select("xpath", "blockquote[contains(.//p/cite//text(), 
'Goethe')]"):first-line {
    color:red;
    background-color:inherit;
}

> > Selectors like ul[count(li)>3 and li[2]/@class='important']
> > currently only are possible with XPath, are they?
>
> I know of ways to express some part of that XPath expression in
> CSS3 Selectors, but not the whole shebang. So the answer to
> that question is afaik "yes".
Yes, the @class='important' part can be expressed in CSS. But the overall 
combination can't.

> > They could be useful:
> >
> > select("xpath", "tr/td[0 > number(concat(.//text()))]") {
> > 	color:red;
> > 	background-color:inherit;
> > }
(just kept that example in case someone gets into this thread and says "Hey 
chris, your XPath expression above is correct but nonsense, noone would ever 
need that, so why..." - I'm just too lazy to think of another good example 
now, but believe me, there *are* many examples where XPath expressions as CSS 
Selectors would be really helpful)

> Yes. As far as I can think of, the only parts of CSS we need
> to combine with XPath, are the pseudo-classes and -elements.
I think so.
I have taken the table of current CSS 2 / 3 Selectors to compare against XPath 
1.0 / 2.0. The table isn't complete yet, but it can already be found at [2].

While writing the document, I thought of another good example of XPath:
select("XPath", "table//tr[position() mod 3 = 0]") {
    background-color:#fed;
}
select("XPath", "table//tr[position() mod 3 = 1]") {
    background-color:#edf;
}
select("XPath", "table//tr[position() mod 3 = 2]") {
    background-color:#dfe;
}
This is not exactly the same as the nth-child selector, because this is a kind 
of nth-descendant-selector.


> I might be wrong though; there can of course be other parts
> of CSS that are essential to the spec., and that doesn't exist
> in XPath. Either way, I don't see why and how they can't be
> combined.
Yes.
Technically, I think except for the pseudo classes and elements, both CSS 
Selectors and XPaths simply select nodes, returning node sets, where CSS 
rules add / modify some properties of these nodes by applying a cascade on 
them (or so, I hope this isn't too far away of the implemented truth ;-)
The selector part is just so similar!

> > Con: The above example also gives a glance of the drawbacks
> > of XPath's power. Imagine a document gets modified, e.g. by
> > ECMAScript using DOM. The dom tree's properties need to be
> > reassigned by reevaluating the selectors against the dom tree.
>
> This is of course an issue that almost all replies have
> mentioned, but let's be serious; isn't this the developer's
> responsibility? If he's such a moron that he uses dynamic
> scripting with XPath/CSS, and this takes like 30 minutes to
> render on his PC, it's really his problem.
Yes, well, I currently don't think XPath will be so much slower than CSS 
Selectors.
XPath could be slower than CSS selectors when using complex XPath expressions, 
but it would give abilities one hadn't when using CSS Selectors.

> This goes for anything stupid that can be done with ECMAScript;
> and there can be done (and is being done) *extremely* much
> stupid, I tell yer!
True, true...

> > Pro: Most UA's already get XPath support for transforming
> > XML documents with XSLT.
>
> At least they get it from components that exists in the OS.
> E.g. Internet Explorer on Windows uses MSXML to transform
> documents. XPath can actually be used as a driver to get
> better XML and XML-related support in browsers.
Well, wether a UA natively supports XPath or via some library is of no 
interest to me, that's the UA vendor's implementation details no one except 
the UA's vendor should have to care about.

> > Pro: The drawbacks sometimes can't not easily or even at all
> > be circumvent under some circumstances, e.g. in content
> > management systems.
> Can you please dredge a bit on this one? I'm not quite
> following you.
If CSS doesn't support XPath, you could use XSLT and XPath to generate an 
appropriate stylesheet and document using lots of ids and classes to 
circumvent the drawbacks of not having XPath Selectors in CSS.
But if you're bound to some content management system, you can't use XSLT and 
XPath anymore to do that, then you're fixed to the abilities the server side 
and the client side system give you, and the CMS on the server side will 
probably not allow any customization via XSLT / Xpath. (Perhaps there are 
some CMS that can, but I'm talking of CMS in general)

> > For a homogenisation, I personally would prefer to take more
> > of XPath's syntax than of CSS' syntax.
> We might step on some toes here, but I agree.
Oh for that case in wise foresight I have taken care and at first stated 
clearly that there was CSS first and then XPath ;-) So the toes should be 
padded and it shouldn't hurt much while I *jump* step *jump* on *jump* them 
<g> (oh, I'm airy, just 52 kg).

> ____
> [1] Disclaimer: I have no idea of how close the XPath WG and
>     CSS WG are working, so in this paragraph I just assume
>     that they are not working close. The reason i assume this,
>     is that I don't think there are many similarities between
>     XPath and CSS Selectors, other than functionality.
I hope the disclaimer isn't copyrighted because I want to claim it for me, 
too.

[2] <http://www.hujer.com/www/selectors>


Bye
- -- 
ITCQIS GmbH
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter (Shareholding CEO)
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE+9gj2zu6h7O/MKZkRAr2NAJ9zIrkWt6PVq6gXciFuS7RwcyTisQCgirU6
4RJIMCy2DE82prenU3++NM4=
=KKom
-----END PGP SIGNATURE-----

Received on Monday, 23 June 2003 04:00:52 UTC