W3C home > Mailing lists > Public > www-style@w3.org > April 2005

Re: XPath & CSS, again

From: Robin Berjon <robin.berjon@expway.fr>
Date: Tue, 12 Apr 2005 11:42:34 +0200
Message-ID: <425B980A.2040805@expway.fr>
To: Bert Bos <bert@w3.org>
Cc: www-style@w3.org

Bert Bos wrote:
> On Friday 08 April 2005 12:32, Robin Berjon wrote:
>>I do very much like the intent of bringing XPath and Selectors
>>together though. W3C made a very serious mistake for which we are
>>still paying the price when it allowed for both to be developed
>>separately,
> 
> I don't think that is the case. The people that developed XPath (mostly 
> James Clark, I believe) knew CSS selectors quite well and still decided 
> to create a different language.

It was necessary to create more, as CSS selectors did not provide 
sufficient expressivity. The difference in syntax however would have 
been largely surmountable had the one and same group been in charge of 
both. It would have avoided the headaches we get today whenever we need 
some selection technology, and picking either isn't better than picking 
both.

The people developing properties for CSS know about XSL, and the people 
developing properties for XSL know CSS, but it doesn't keep anyone in 
there from producing a big soup of properties with the same names and 
completely different values so that other WGs don't know if they should 
adopt one, the other, or just give up and come up with their own. Just 
because someone knows of someone else's work doesn mean the differences 
aren't gratuitous.

> The syntax of CSS selectors is optimised for its particular goal, viz., 
> selecting elements (and moreover, elements in text documents, i.e., in 
> relatively simple trees). E.g., it separates elements by whitespace, 
> which looks good and is easy to type, but makes it difficult to put a 
> selector in a URL. It also has special syntax for CLASS attributes.
> 
> I think XPath has different goals, viz., selecting not just elements, 
> but also individual attributes, comments, etc. And it is meant to be 
> used by a different group of people. That is why it has a different 
> syntax. Note that not only does it lack special syntax for CLASS 
> attributes, it *can't* select on CLASS attributes at all. (With XSLT, 
> my estimate is that you need about 50 lines to select an element with a 
> certain CLASS. With the new regular expressions in XPath 2.0 it is 
> tricky, but possible within XPath.) Clearly that is not what XPath was 
> designed for.

I'm sorry but the class argument does not stand for a single second. 
It's just a frictional difference stemming from the fact that the two 
weren't developed in unison. Had they been, a class selector could have 
easily been added to XPath (as you can trivially add a css:class() 
function today).

The fact that XPath has a richer data model than CSS is also a poor 
argument. XPath was designed from the start to be harmlessly subsetted 
(XSLT subsets it in its patterns) and CSS could have used such a subset.

Separation by whitespace doesn't mean much more either. It's just 
syntax. A merged language could have used either that, or something else.

> The model of XML (and SGML) that selectors uses is quite simple: there 
> are elements and attributes, the elements are ordered in a tree and the 
> attribute values are either strings, space-separated strings or 
> dash-separated strings (or all at the same time). That's it. Comments, 
> PIs, character entities, notations, external entities, CDATA sections, 
> DTD subsets... all these things don't exist. So that is clearly a 
> subset of the DOM and the XML infoset.

Yes, there's an almost trivial subset there. They match.

> On the other hand, selectors are also used for selecting typographical 
> things (:first-line, :first-letter) and elements with information 
> outside the tree (:visited, :focus. :lang). That is not a goal for 
> XPath and if you use XPath in an interactive rendering application, you 
> would need to define extension functions.

Which would have been very simple, XSLT does it for its own purposes.

> As long as the underlying models of XML are compatible (and I believe 
> they are), both should use the syntax that best matches their goals. We 
> don't want a large number of similar but gratuitously different 
> languages, but when two applications are clearly different, then so 
> should their languages. (Otherwise, why do you use Perl, isn't C 
> enough?)

I don't think the two applications are clearly different at all. If they 
were we would never be having to decide which one to use in a given 
context. Nevertheless, that just keeps happening (see the Binding TF for 
an example). Or if you mean to say that CSS selectors should never be 
used outside CSS, you might wish to consider renaming 
http://www.w3.org/TR/css3-selectors/ to "CSS Selectors" to make that clear.

> If CSS selectors had looked like XPath, we wouldn't have had style 
> sheets on the Web today.

I think that's a bold and unverifiable statement, with which I'll boldly 
and unverifiably disagree! There aren't many CSS selection constructs 
that are in wide use today, and all were in CSS 1.0. I highly doubt the 
syntaxes would have gotten in the way.

   CSS         XPath (pattern context)
   element     element
   *           *
   el desc     el//desc
   #foo        id('foo')
   .bar        class('bar')
   :hover      hover()

I don't think the difference would have prevented CSS's deployment on 
the Web. Or reversing it, I don't think it would have prevented XPath's 
success.

-- 
Robin Berjon
   Research Scientist
   Expway, http://expway.com/
Received on Tuesday, 12 April 2005 09:42:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:36 GMT