Whereas xpath... does not. Which is a severe understatement considering the equivalent to the CSS selector you wrote up (or to `.foo`) in xpath 1 is something along the lines of:

    [contains(concat(' ', normalize-space(@class), ' '), ' foo ')]

the normalize-space can be dropped IIF you're certain all spaces are normalized, the spaces around the needle not.

xpath 2 does quite a bit better through `tokenize`:

    //*[tokenize(@class, '\s+')='foo']

but still not great. And god forbid you need to match multiple classes in the same selector.

[0] or xpath 1 + exslt if your xpath implementation provides it. exslt actually does slightly better as the pattern is optional and defaults to whitespace characters

Over in .NET land we appear to be stuck on XPath 1.0 forever. A project I used to work on used it extensively, but I now use the HtmlAgilityPack (badly formatted HTML) or XDocument (XHTML strict or XML) where I have the choice.

> Over in .NET land we appear to be stuck on XPath 1.0 forever.

I don't think it's a bad idea, most of the improvements in XPath 2 are the new standard functions which depending on your XPath implementation may be available as extensions (e.g. tokenize comes from exslt, an xpath 1.0 library) but along with that it brings significantly higher complexity and I think the spec has gone from "difficult to read" to "meaningless word-salad".

I really like XPath, but I can't say I was impressed by XPath 2, it loses much of xpath's simplicity with little to show for the added complexity.