In Selenium, how does an absolute XPath differ from a relative XPath that begins with a double slash?

## What each slash actually means A leading `/` does not select the `<html>` element. It selects the **document root node** — the node that contains `<html>` — and every `/` after it introduces one **step**. Steps default to the `child` axis, so the path most people write as `/html/body/table/tbody/tr[2]/td[1]` is really the abbreviation of `/child::html/child::body/child::table/child::tbody/child::tr[2]/child::td[1]`. Read it as a literal walk: from the root, into `html`, into `body`, into `table`, into `tbody`, take the second `tr`, take its first `td`. Nothing is searched for; every level is named. ## `//` is a real axis step, not a wildcard `//` is the abbreviation for `/descendant-or-self::node()/`. So `//td` expands to `/descendant-or-self::node()/child::td` and means "any `td` element anywhere below the root, at any depth". Three consequences follow: - Because it expands to a **step**, `//` can appear in the middle of a path: `//table[@id='mooring-chart']//button[@class='release']` is legal and means "any release button at any depth below that table". - Because the expansion still begins with `/`, a `//` path is formally an **absolute location path** too. The everyday Selenium distinction — "absolute" meaning full path from the root, "relative" meaning search from anywhere — is a working vocabulary, not the XPath specification's own. - `//` is not a name wildcard. The wildcard for an element name is `*`, as in `//*[@id='mooring-chart']`. ## The descendant axis behind the abbreviation Writing the axis out longhand shows what the abbreviation buys and where it differs: - `//td` is `/descendant-or-self::node()/child::td`. It starts at the root, drops to the root **or any node beneath it**, and then takes `td` children of each — every `td` on the page. - `/descendant::td` is not quite the same step. `descendant` excludes the context node itself, and it selects descendants directly rather than by taking a child step, so `//self::html` matches the `html` element while `/descendant::html` does not. - `/html/body//td` anchors the search: the abbreviation is a step like any other, so everything to its left constrains where the descendant search begins. - `..` is the abbreviation for `parent::node()`, which is how a path steps back up one level mid-expression, as in `//td[@class='boat']/../td[@class='slip']`. The practical reading: a leading `//` is a search over the whole document, and a mid-path `//` is a search over one subtree. Neither says anything about how deep the target sits. ## Where an absolute path over the mooring chart breaks 1. **The implicit `tbody`.** The browser's HTML parser inserts a `tbody` element into the DOM for a table even when the source markup omits it. A path copied out of the raw HTML as `/html/body/table/tr[1]` therefore matches nothing, while `/html/body/table/tbody/tr[1]` works. This is the single most common reason a hand-written absolute path finds nothing on a chart that clearly renders. 2. **An inserted wrapper.** Wrapping the chart in one `<div class="panel">` shifts every step after `body` by a level and invalidates the entire path. 3. **A shifting row index.** `tr[2]` names the second row *positionally*. Add a header row or a filter row and it now points at a different mooring. 4. **A conditionally rendered element.** A slot that only appears for reserved slips changes the sibling numbering for the rows around it. None of that touches a relative path anchored on an identifier, because it names none of the intervening structure. ## The two forms side by side | | `/html/body/table/tbody/tr[2]/td[1]` | `//table[@id='mooring-chart']//td[@class='slip']` | |---|---|---| | Starting point | document root | document root, then every descendant | | Depth | fixed and fully spelled out | any | | Named structure | every level between root and target | only the anchor and the target | | Typical failure | one inserted level breaks it | over-matching when the anchor is too loose | | How you read it | a route | a description | ## Keeping a relative path from over-matching A bare `//td[1]` is relative and useless: it matches the first cell of every row of every table on the page. The fix is not to lengthen the path back into an absolute one, it is to add an **anchor step** with a predicate that identifies the region: - Anchor on a stable attribute: `//table[@id='mooring-chart']//td[@class='slip']`. - Anchor on content the row owns: `//td[normalize-space()='Sea Wren']`. - Prefer a predicate to a depth: `//tr[@data-status='reserved']` says what you mean; `/html/body/div/div/table/tbody/tr[4]` says where it happened to sit. ## What Selenium does with either string Both forms travel identically. `By.xpath("...")` produces the `xpath` location strategy on the wire, and the remote end evaluates the string with `document.evaluate` against the document. There is no separate "absolute mode" and no client-side parsing of the path — Selenium never inspects the shape of the expression. A syntactically broken expression comes back as `InvalidSelectorException`; a syntactically valid expression that simply matches nothing comes back as `NoSuchElementException` from `findElement`.