In Selenium, can a CSS locator select an element by what it contains, and when must XPath take over?

## CSS combinators only travel down or forward Every combinator in CSS moves in one direction. The descendant combinator (a space) reaches inside an element, the child combinator `>` reaches one level inside, `+` reaches the next sibling and `~` reaches a later sibling. There is no parent combinator, and the `<` that people write from memory has never been part of the language. That is a real constraint on a Selenium locator, because `By.cssSelector` hands your string to the browser's own engine untouched and gets back whatever that engine can express. On a stadium ticket exchange the shape of the problem is always the same: you can see the thing that identifies the row — a sold-out badge, a seat number, a block code — and you need the row, or a button inside the row, not the marker itself. ## `:has()` is the one relational pseudo-class `:has()` closed most of this gap. In `tr.listing:has(span.badge--sold)` the **subject** of the selector is still the `tr`; the argument is a condition evaluated relative to it. So "the listing row that contains a sold badge" is expressible in CSS, and Selenium gets it for nothing, because the client does not interpret the string — it forwards it. That makes a whole family of locators possible without leaving CSS: - `tr.listing:has(span.badge--sold) button.resell` — the resell button inside a sold-out row. - `tr.listing:not(:has(span.badge--sold))` — every row that is *not* sold out, combining negation with containment. - `tr.listing:has(td.seat[data-block="118"])` — the row for a given block, matched on an attribute of a cell. ## Where it still stops Three limits survive, and a senior answer names them: - **No text.** `:has(td.seat:contains("118-K"))` is not CSS. Containment can test structure and attributes; it cannot test the characters rendered inside an element. - **Engine support is the browser's, not Selenium's.** Nothing in the client polyfills `:has()`. An engine that does not implement it fails to parse the selector and returns the `invalid selector` error, so the same test passes on one browser in a matrix run and fails on another, with an error that reads like a typo. That symptom — one browser, invalid selector, a modern pseudo-class in the locator — is the diagnosis worth recognising. - **You express containment, not an axis hop.** `:has()` says "a row that contains this"; it does not say "the nearest ancestor row of this element". With nested tables or repeated wrappers those are not the same statement, and the CSS version can match more rows than you intended. ## The XPath fallback Where CSS runs out, `By.xpath` does both missing jobs at once — matching on rendered characters and walking upward: ```java WebElement resell = driver.findElement( By.xpath("//td[normalize-space()='118-K']/ancestor::tr[1]//button[@class='resell']")); ``` That is the fallback the leaf name implies: not a wholesale switch of locator style, but reaching for the one expression language that can phrase the thing CSS cannot. ## Or climb in the client, from an element you already hold If a CSS locator already found the inner element, the DOM's own `closest()` walks up from it, and `JavascriptExecutor` can run it: | What you need | CSS locator | Fallback when CSS cannot | |---|---|---| | the row containing a sold badge | `tr.listing:has(span.badge--sold)` | XPath, on an engine without `:has()` | | the row whose seat cell reads `118-K` | none possible | XPath text predicate, or `closest()` in a script | | every row that is not sold out | `tr.listing:not([data-status="sold"])` | not needed | | the third listing row | `tr.listing:nth-of-type(3)` | not needed | ## A decision procedure you can say out loud 1. Can the condition be phrased on tags, classes, attributes or structural position? Then it is a plain CSS locator and nothing else is required. 2. Is the condition "contains something", and does every browser in the run implement `:has()`? Then stay in CSS and use it. 3. Does it involve **rendered text**, or an upward hop that containment cannot phrase? Then that one locator becomes XPath. 4. Do you already hold the inner element? Then `closest()` through `executeScript` gets you the ancestor without a second full-document search. The point a senior answer lands is that this is a **capability** question, not a preference. CSS is not "weaker" in some vague sense; it lacks exactly two things a test needs — character data and upward traversal — and one of those two has been partly closed by `:has()` in engines new enough to have it.