4 ms·

It would have made sense to use XPath for CSS selectors, or at least make the CSS selectors a syntax compatible subset if you wanted to them piecewise in functi

It would have made sense to use XPath for CSS selectors, or at least make the CSS selectors a syntax compatible subset if you wanted to them piecewise in functionality like they currently have done.

bryanrasmussen 6y ago
Well, I believe that Håkon Wium Lie would never have let that happen, but hey could be misreading his stance on things.
- masklinn 6y ago
  The main reason why it wouldn't have happened is CSS selectors predate XPath by a few years. CSS was first proposed in 1994 and the CSS1 spec was released in 1996, I don't know when XPath was originally proposed but the first public draft was in late 1998 and the release was in 1999. CSS 2 actually predates XPath 1.0. XPath would also have needed more work to replace CSS selectors, aside from being a bigger performance concern (through being more capable and not working in a strictly top-down manner, meaning you can easily get very inefficient selectors) it lacks facilities which are quite critical to CSS selectors like the shortcut id and class selectors as well as priority. In fact talking about class selectors, those are absolute hell to replicate in XPath 1.0 if you don't have extensions to lean on. To replicate the humble `.foo` you need something along the lines of //*[contains(concat(' ', normalize-space(@class), ' '), ' foo ')] And don't miss the spaces around the name of the class you're looking for, they're quite critical. Good fucking luck if you need to combine multiple classes. exslt/xpath 2.0 have `tokenize` which make it much more convenient although IIRC the way it's used is weird, I think it's //*[tokenize(@class) = 'foo'] because "=" on a nodeset is really a containment operation? Not sure. There's also `matches` but that's error-prone because classes tend to be caterpillar-separated, and your friendly neighborhood `\b` will match those so you need to mess around with `(^|\s+)` bullshit instead. And finally I believe xpath 3.1 has a straightforward "contains-token" which does what the CSS "~=" operator does. XPath 3.1 was released in 2017. "~=" was part of CSS2 (CSS1 didn't have "arbitrary" attribute selection, only classes and ids).
  - bryanrasmussen 6y ago
    well, I know XPath 1.0 was released in 1999 because I was doing stuff with it. CSS 2 as I remember was some years after that, and googling it seems to be August 2002. At any rate in this example //*[contains(concat(' ', normalize-space(@class), ' '), ' foo ')] I don't think the interest in using XPath is at all related to being able to check what class an element has, and in fact the linked discussion does not have anything to do with that, so I mean yeah, that's pretty bad but not anything anyone is asking to do in this scenario.
    - masklinn 6y ago
      > CSS 2 as I remember was some years after that, and googling it seems to be August 2002. You're thinking about CSS 2 revision 1 aka CSS 2.1 > I don't think the interest in using XPath is at all related to being able to check what class an element has The original comment in the thread was > It would have made sense to use XPath for CSS selectors Being able to check what class an element has would be absolutely critical to that use-case.
      - bryanrasmussen 6y ago
        ah yeah, forgot we were in thread and was thinking about the post itself.
  - admax88q 6y ago
    Yeah maybe not the best idea, XPath has a pretty different use case than CSS. But it does seem a shame that more complex "nth-child" selectors do not just use something more flexible/programmable like xpath. As it stands CSS keeps adding one-off selectors such as nth-child, only-child, only-of-type. Such is the feature creep of web standards as they are, a continual addition of one-off APIs for specific use cases rather than a robust orthogonal programming platform that people can build anything on top of, like WebCrypto instead of adding integers.
  - sergeykish 6y ago
    XPath works with XML, class is a mini language. We had same problem in JavaScript until classList $(element).attr("class").split(/\s+/) It is side effect of one attribute name per element <a class=foo class=bar> //*[@class = 'foo'] //*[@class = 'bar'] or having attributes at all <a> <class>foo</class> <class>bar</class> </a> //*[class = 'foo'] //*[class = 'bar'] Of course `class` access would be optimized like it is today.
bawolff 6y ago
Well im glad they didn't CSS is a beautifly intuitive query language. XPath is an ugly non-intuitive syntax. I suspect that's part of the reason that it didn't take off (ux of apis matter)

It would have made sense to use XPath for CSS selectors, or at least make the CSS selectors a syntax compatible subset if you wanted to them piecewise in functionality like they currently have done.

bryanrasmussen 6y ago

Well, I believe that Håkon Wium Lie would never have let that happen, but hey could be misreading his stance on things.

masklinn 6y ago
The main reason why it wouldn't have happened is CSS selectors predate XPath by a few years. CSS was first proposed in 1994 and the CSS1 spec was released in 1996, I don't know when XPath was originally proposed but the first public draft was in late 1998 and the release was in 1999. CSS 2 actually predates XPath 1.0. XPath would also have needed more work to replace CSS selectors, aside from being a bigger performance concern (through being more capable and not working in a strictly top-down manner, meaning you can easily get very inefficient selectors) it lacks facilities which are quite critical to CSS selectors like the shortcut id and class selectors as well as priority. In fact talking about class selectors, those are absolute hell to replicate in XPath 1.0 if you don't have extensions to lean on. To replicate the humble `.foo` you need something along the lines of //*[contains(concat(' ', normalize-space(@class), ' '), ' foo ')] And don't miss the spaces around the name of the class you're looking for, they're quite critical. Good fucking luck if you need to combine multiple classes. exslt/xpath 2.0 have `tokenize` which make it much more convenient although IIRC the way it's used is weird, I think it's //*[tokenize(@class) = 'foo'] because "=" on a nodeset is really a containment operation? Not sure. There's also `matches` but that's error-prone because classes tend to be caterpillar-separated, and your friendly neighborhood `\b` will match those so you need to mess around with `(^|\s+)` bullshit instead. And finally I believe xpath 3.1 has a straightforward "contains-token" which does what the CSS "~=" operator does. XPath 3.1 was released in 2017. "~=" was part of CSS2 (CSS1 didn't have "arbitrary" attribute selection, only classes and ids).
- bryanrasmussen 6y ago
  well, I know XPath 1.0 was released in 1999 because I was doing stuff with it. CSS 2 as I remember was some years after that, and googling it seems to be August 2002. At any rate in this example //*[contains(concat(' ', normalize-space(@class), ' '), ' foo ')] I don't think the interest in using XPath is at all related to being able to check what class an element has, and in fact the linked discussion does not have anything to do with that, so I mean yeah, that's pretty bad but not anything anyone is asking to do in this scenario.
  - masklinn 6y ago
    > CSS 2 as I remember was some years after that, and googling it seems to be August 2002. You're thinking about CSS 2 revision 1 aka CSS 2.1 > I don't think the interest in using XPath is at all related to being able to check what class an element has The original comment in the thread was > It would have made sense to use XPath for CSS selectors Being able to check what class an element has would be absolutely critical to that use-case.
    - bryanrasmussen 6y ago
      ah yeah, forgot we were in thread and was thinking about the post itself.
- admax88q 6y ago
  Yeah maybe not the best idea, XPath has a pretty different use case than CSS. But it does seem a shame that more complex "nth-child" selectors do not just use something more flexible/programmable like xpath. As it stands CSS keeps adding one-off selectors such as nth-child, only-child, only-of-type. Such is the feature creep of web standards as they are, a continual addition of one-off APIs for specific use cases rather than a robust orthogonal programming platform that people can build anything on top of, like WebCrypto instead of adding integers.
- sergeykish 6y ago
  XPath works with XML, class is a mini language. We had same problem in JavaScript until classList $(element).attr("class").split(/\s+/) It is side effect of one attribute name per element <a class=foo class=bar> //*[@class = 'foo'] //*[@class = 'bar'] or having attributes at all <a> <class>foo</class> <class>bar</class> </a> //*[class = 'foo'] //*[class = 'bar'] Of course `class` access would be optimized like it is today.

bawolff 6y ago

Well im glad they didn't CSS is a beautifly intuitive query language. XPath is an ugly non-intuitive syntax. I suspect that's part of the reason that it didn't take off (ux of apis matter)