I generally prefer CSS selectors over XPath when writing Selenium locators. CSS selectors are concise, readable, and usually provide everything I need.
However, there are situations where XPath is a better fit—particularly when I need to navigate through an element's hierarchy, such as moving from an element to its parent, grandparent, or sibling.
This post shows one such real-world example.
The Problem
I came across a situation where I needed to click a link based on the value of an input field.
The HTML structure contained multiple similar groups of elements. The input field and the link I wanted to click were not directly related, but they shared a common parent structure.
In the following example above, the input element is highlighted, and I need to click the corresponding anchor (<a>) element.
The challenge is that there may be multiple similar structures on the page. I therefore need to locate the link relative to the particular input element rather than using a fixed locator for the link itself.
Step 1: Navigate from the Input to Its Parent
First, I locate the input element based on its value attribute:
//input[contains(@value, '.')]From this input element, I need to move up through two parent <div> elements.
XPath provides the parent axis for exactly this purpose:
//input[contains(@value, '.')]/parent::div/parent::divThis takes us from:
input
↓
parent div
↓
parent divStep 2: Navigate to the Previous Sibling
Once I reach the required parent <div>, I need to move to its preceding sibling.
The XPath preceding-sibling axis allows us to do that:
//input[contains(@value, '.')]/parent::div
/parent::div/preceding-sibling::divNow we have moved from the input element to the sibling <div> containing the link.
Step 3: Locate the Link
Finally, I can select the required anchor element:
//input[contains(@value, '.')]/parent::div
/parent::div/preceding-sibling::div/a[2]The complete navigation can therefore be visualized as:
input
↓
parent div
↓
parent div
↓
preceding sibling div
↓
second anchorThis is one of the situations where XPath becomes particularly useful. Instead of relying on a unique ID, class, or other attribute on the target link, we locate it relative to another element that we can identify reliably.
A Shorter XPath
I originally posted this question to the WebDriver Google Group, where Luke suggested a shorter XPath:
//input[contains(@value, '.')]/../..
/preceding-sibling::div/a[2]This achieves essentially the same result.
Instead of explicitly using the parent::div axis twice:
/parent::div/parent::divwe can simply use:
/../..So:
//input[contains(@value, '.')]/parent::div
/parent::div/preceding-sibling::div/a[2]becomes:
//input[contains(@value, '.')]/../..
/preceding-sibling::div/a[2]Personally, I find the first version more descriptive because it makes the XPath axes explicit. The shorter version is more compact, but both are valid approaches.
XPath Axes Worth Knowing
This example also demonstrates several useful XPath axes:
parent— moves to the parent of the current element.preceding-sibling— selects siblings that appear before the current element.following-sibling— selects siblings that appear after the current element.ancestor— moves to any ancestor element.descendant— selects elements contained within the current element.
Understanding these axes can make XPath much more powerful when dealing with complex or dynamically generated HTML.
CSS or XPath?
I still prefer CSS selectors whenever they can express the relationship clearly.
However, XPath is extremely useful when the locator needs to navigate through the DOM rather than simply identify an element.
When this article was originally written, CSS selectors did not provide a practical way to move from an element to its parent. Modern CSS has since evolved and supports the :has() relational pseudo-class, which can express some relationships that previously required XPath.
Even so, XPath remains an important tool in a Selenium engineer's toolbox—especially when you need explicit DOM navigation using axes such as parent, ancestor, or preceding-sibling.
The lesson is not “always use XPath.”
It is:
Use the simplest locator that reliably expresses the relationship you need.
For straightforward element identification, CSS is often my first choice. When the relationship between elements becomes more complex, XPath can be the cleaner solution.