XPath: Is It a UI Smell?

An excellent conversation popped up on Slack about XPaths vs CSS selectors recently.

One member said

It’s more powerful than CSS. There are things that Xpath can do that CSS cannot. You can do things like find text containing etc… I have used it before for a particularly complicated cases where I needed to find all the specific elements after a certain element number (It was a dynamic site and had a draggable row, that was coded in html to be similar to the other rows but slightly different. Can’t remember the exact use case but it was not remotely possible in CSS)

I think… Xpath gets a bad rep… because people don’t read too much into it, and see horrible absolute xpaths copied directly out of chrome that look like this /body/div/div/div/span[4]...

I agree that is horrible :point_up: . But that is not good xpath.

it gets a bad rep because most examples are copied directly out of the browser.

I am genuinely suprised, that CSS seems to be the dominant selector over xpath, I feel had we better educational resources on xpath, it would be the dominant selector as you can do more with it

A better answer would probably list what you can do in xpath vs CSS

Another member said

i see the point of the bigger feature set. but the need to use these features is a smell to me, a bandaid on the underlying problem that your UI isn’t well structured, the html not very descriptive.
also the smaller feature set and less special characters makes selectors better to learn, read and maintain in my opinion.

Both posters agreed that they’d seen some very poorly written CSS selectors over the years too though.

What do you think? Is XPath a UI smell?


It could well be! Is was also developed as a part of XQuery, a very useful functional language for manipulating XML. I have used it to program using the open source database eXist. Together with XSLT I found it very easy to test and get right, since one can test the XSLT transforms with simple visual tools whilst developing and the simply set up test suites with the XML input and output. The XQuery code is also rather simple to test, since there are no global writable variables. What goes into an XQuery function must come out. The testing tools in eXist are rather primitive. I have not used the commercial XML database MarkLogic. That might be better. But as a sort of replacement for JQuery and CSS selectors I don’t know. Whenever somebody starts writing HTML, they write <div> before even thinking.

1 Like

I have also been wondering why XPath is not so popular. I personally like to use relative XPath to locate web elements. I know some browsers have extensions that help you get the relative and absolute XPaths. This makes it easy sometimes. Chrome has ChroPath. and older versions of Firefox had FirePath.

1 Like

XPath is not appreciated enough.

People talk about the slowness of XPath like it’s something that they can measure and that can actually make a difference.

But the same people will have no problem with using a CSS Selector.
Maybe because CSS Selectors are easier to use with JavaScript and everything seems to be about JavaScript these days.

Writing XPaths and CSS Selectors is a fantastic skill and we wrote a short tutorial for our users here:
Finding Elements in Web Applications

And we also wrote a blog post about it:
A Practical Guide for Finding Elements with Selenium

I’m constantly trying to encourage people to learn this skill.


I can’t say I’m a fan of XPath and don’t enjoy reading through it at all, but I have seen instances, using WebDriver, where xpath is more consistent. For example, on a current system under test navigating through some of the menus can be done By.xpath or By.cssSelector (excuse the pun). In this instance, the latter is usually quite a bit more readable! Quite late on in my development, when running the code a lot more intensively, I found WebDriver would occasionally randomly decide a perfectly visible (and previously working/interactable) thing was not interactable at all.

I have no idea if this is a bug in the underlying framework, used by the software engineers, or a bug with WebDriver, but found switching to xpath* worked like a charm. And this is testing a system that has been largely very pleasant to automate, owned by a very cooperative software engineer** - I feel for those who must work on some of the inevitable nightmares out there.

* After trying explicit waits, hovers and so on. Sometimes WebDriver just doesn’t want to work with an element when I think it should.

** It’s an older team, with quite a few CAMRA members, so pretty chilled. There’s nothing that can’t be solved over a beer.

1 Like

Absolute XPath is unquestionably a UI smell.

Relative XPath… depends.

Unfortunately, a number of web frameworks use dynamic IDs and names, leaving the poor sod automating the thing with few choices. A well chosen CSS locator or a well chosen XPath locator isn’t a code smell.

1 Like