- From: Bert Bos <bert@w3.org>
- Date: Mon, 11 Apr 2005 20:20:08 +0200
- To: www-style@w3.org
On Friday 08 April 2005 12:32, Robin Berjon wrote: > Pascal Schmitt wrote: > > What about using XPath with CSS? > > It could be done. The argument I've heard the most is that since > XPath is more complete and more general it would have performance > issues compared to Selectors which were pretty much designed just for > CSS (which is why they are almost never reused outside). I haven't > seen numbers to back that up, but I would tend to believe it could be > true. > > 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. 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. > and anything done to bring them back together can only > help. I'm not convinced that merging the syntaxes in the way you > propose is the way to go. I have been thinking along the lines of > defining a CSS-compatible subset of XPath (since Selectors are > largely a subset, with very little that's not in XPath or couldn't be > expressed in it) so that one could use either in the same context > with implementations only having to deal with different syntaxes. 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. 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. > > I'm not sure what the steps beyond that would be, but any step > towards better integration would be helpful. 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?) If CSS selectors had looked like XPath, we wouldn't have had style sheets on the Web today. And if XPath syntax had been an extension of CSS syntax, it would probably have been more verbose and less readable than it is today for all but the simplest expressions. Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos W3C/ERCIM bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Monday, 11 April 2005 18:20:16 UTC