Lately, I’ve been doing a lot of work building a parser for both XPath and CSS 3 – and I was amazed at just how similar they are, in some respects – but wholly different in others. For example, CSS is completely tuned to be used with HTML, with the use of #id (to get something by ID) and .class (to get something by its class). On the other hand, XPath has to ability to traverse back up the DOM tree with .. and test for existance with foo[bar] (foo has a bar element child). The biggest thing to realize is that CSS Selectors are, typically, very short – but woefully underpowered, when compared to XPath.
I thought it would be worth some merit to do a side-by-side comparison of the different syntaxes of the two selectors.
|All P Elements||p||//p|
|All Child Elements||p > *||//p/*|
|Element By ID||#foo||//*[@id=’foo’]|
|Element By Class||.foo||//*[contains(@class,’foo’)] 1|
|Element With Attribute||*[title]||//*[@title]|
|First Child of All P||p > *:first-child||//p/*|
|All P with an A child||Not possible||//p[a]|
|Next Element||p + *||//p/following-sibling::*|
Syntactically, I was surprised how similar the two selectors were, in some cases – especially between the ‘>’ and ‘/’ tokens. While they don’t always mean the same thing (depending on what axis you’re using in XPath), they’re generally assumed to mean the child element of the parent. Also, the ‘ ‘ (space) and ‘//’ both mean ‘all descendants of the current element’. Finally, the ‘*’ means ‘all elements’, regardless of their name, in both.
Even though I already knew all of this ahead of time – it’s certainly nice being able to rediscover the similarities when it comes down actually having to program an implementation of them.
1 This isn’t right due to the fact that it would match ‘foobar’ and ‘foo bar’, when only the second pattern is correct. The actual syntax would be far more complex and would probably require multiple expressions to get the job done.