Re: XPath (kind of) as CSS Selectors

* Orion Adrian wrote:
>I've been noticing a convergence recently of XPath and CSS Selectors 
>recently. It becomes very obvious when looking at CSS3.

The structural part of css3-selectors is basically a subset of XPath
1.0, I wrote two implementations of this very part on top of XPath
engines (by rewriting selectors into XPath expressions).

>After having read the arguments back and forth, I noticed one of big 
>complaints was that performance would be an issue and that CSS selectors 
>make sure that they can be calculated by their parents and immediate 
>sibblings only.

Css3-selectors does not, :last-of-type and :only-of-type require to know
about all siblings in their worst case. AFAIR, the argument was rather
we should not make things worse.

>But there is no reason that one couldn't work with the XPath spec to create 
>a subset of XPath axes and functions for use in CSS. The problematic ones as 
>I see it are anything that looks at descendants of an element. Therefore you 
>simply remove these axes.

I don't really see the benefit here. I would whole-heartedly agree that
writing XPath expression is much simpler than writing the corresponding
css3-selectors, you don't have to remember all these special names,
special characters and special syntax and you could use the same syntax
whether you author XSLT, XForms, XML Schema, Schematron, ... or program
using the various proprietary XPath selection interfaces or DOM Level 3
XPath, etc.pp. but subsetting XPath to something that would no longer be
a superset of css3-selectors, which is what you would likely end up in
order to reduce the objections to such a proposal, would just confuse
authors.

Also note that my impression is that some people seriously consider
css3-selectors "simpler" than XPath. I don't really understand why,
it's hard to believe that I am the only one who has trouble to
understand what selectors (plural) like

  :nth-last-child(2n+3)   :nth-last-child(2n-2)  :nth-last-child(2n-3)
  :nth-last-child(-2n+1)  :nth-last-child(-1n+6) :nth-last-child(-2)
  :nth-last-child(--7n-2) :nth-last-child(+0n)   :nth-last-child(-2n-2)
  :nth-last-child(-n-2)   :nth-last-child(+7)    :nth-last-child(n-1)

actually match (if anything) especially without looking at the spec,
I already have trouble to write ~= as I am used to write =~ and I
virtually always have to check the specification whether + and ~ refer
to preceding or following siblings and which of those (if any) requires
adjacency, I sometimes even think that in A~B or A+B A is the acutal
subject.

Writing selectors is also much more difficult for me, when I try to
determine the proper selector for some elements I start with the element
and look what conditions need to be met to match, XPath allows me to
write E[conditions] which seems much more natural to me. Also, due to
the syntax overlap, I sometimes confuse concepts, E:not(B) looks all to
similar to E[not(B)] though the selector selects an E element that is
not a B element (all E elements) while the XPath expression selects E
elements without a B child (or E elements not a parent of a B element).

For me there seems to be no benefit in having two structural selection
languages, it rather seems to be a matter of likes and dislikes...

Though, btw, there is nothing that stops you from using XPath tody, even
Internet Explorer 6.0 ships with a full XPath 1.0 implementation, you
just need some e.g. JavaScript code to use the selection engine. But it
would require ActiveX to use it for web pages, hmm, but then, authors
apparently do not care much, "IE7" relies on ActiveX, too, maybe I am
the only one who turned ActiveX off for most sites...

>That still leaves you with a powerful set of selectors and more importantly 
>a unified syntax. I forsee more and more elements being added to both 
>languages and them growing apart in places, but for the most part ending up 
>with the same feature set and slightly different languages.

Well, the css3-selectors Recommendation will probably have less features
than the current Candidate Recommendation and the CR already has
basically less features than earlier Working Drafts. I don't see much
growth here. Also note that the css3-selectors CR is 2 1/2 years old and
implementations... well, I alone wrote two of them, so it's probably not
that bad; though that doesn't help much...

>Some basic example of how CSS3 selectors use the same model as XPath 1.0

Note that the css3-selectores CR requires to have information that is
not available in the XPath data model such as information about
defaulted attribute values or empty text nodes. Your comparison also
does not involve namespaces...

>CSS: E:root
>XPath: /E[self:E]

That would be self::E which is not needed, /E is already sufficient.

>CSS: E:empty
>XPath: E[not(*)]

No, :empty would rather be E[not(node())], that's closer to the
specification but still not conforming as empty text nodes are not
considered. The css3-selectors test suite expects that :empty works
like E[not(* or text())].

>CSS:  E.warning
>XPath: E[@class="warning"]

It's probably more like

  [. = 'green' or
   starts-with(., 'green ') or
   contains(., ' green ') or
   substring(., string-length(.) - string-length('green')) = ' ']

if the @class attribute is the context node; but this depends on the
definition of the class attribute which is language specific and not
really well-defined, the specificiations are not really in agreement
etc. Just note that you can have multiple classes and if you do, =
would not match.

>CSS: E#myid
>XPath: E[@id="myid"]

There is an id() function in XPath.

>* The following CSS selectors have no example because I couldn't come up 
>with one in a short period of time. Some of them may be possible. Feel free 
>to insert examples that work. *

AFAIR, there is only a single "limitation" in XPath that makes it
difficult to express selectors as XPath expressions, namely, the
-of-type pseudo-classes attached to the universal selector. You would
need to generate the expression for each element.

Received on Monday, 19 April 2004 16:48:39 UTC