Relative Locators: Compatibility Boundary for CSS‑Transformed Reference Elements in Selenium 4

Short answer

Don't rely on relative locators (above, below, leftOf, rightOf, near) when the reference element has a non-identity CSS transform. Selenium 4 computes relative positions from the rectangle returned by the WebDriver Get Element Rect command, and that rectangle is the element's layout box — the spec does not require it to incorporate the transform matrix. So the locator is answering "what is above the element's untransformed box", not "what is above what the user sees". Until the W3C WebDriver spec defines transform handling for element rects, treat transformed reference elements as outside the supported boundary for relative locators.

Confirmed facts vs. likely explanation

Confirmed: Selenium's relative locator implementation builds its search from each candidate's getRect() values, which come straight from the driver's Get Element Rect endpoint. The WebDriver specification defines that rect in layout terms and is silent on transforms, overflow clipping, and stacking. That silence is exactly why behavior can diverge across Chrome/ChromeDriver, Firefox/geckodriver, and Edge — each driver team makes its own reasonable choice, and those choices can differ, especially for 3D transforms or transforms combined with fixed positioning.

Likely explanation (not confirmed): the cross-browser discrepancies you observe probably come from drivers differing on whether the returned rect is pre- or post-transform, plus the fact that the relative-locator algorithm itself never accounts for clipping or z-order. I can't verify per-driver behavior from here, so treat this as a hypothesis to test, not a fact.

What to do in your tests

1. Prefer stable locators. If the target has an ID, test ID, or unique CSS/XPath path, use it. Relative locators are a fallback for visually-defined relationships, and transforms break the visual/layout equivalence they assume.
2. If you must use them, neutralize the transform first via JavaScript, then locate, then restore:

js.executeScript("arguments[0].style.transform='none'", ref);
WebElement target = driver.findElement(
    RelativeLocator.with(By.cssSelector(".target")).above(ref));
js.executeScript("arguments[0].style.transform=''", ref);

Note this changes the rendered page mid-test, so only do it where the visual state doesn't matter for the assertion.

Alternative: read the true visual box with getBoundingClientRect() (which does apply transforms) and implement the above/below comparison yourself against candidate elements' rects. That gives you one algorithm under your control, identical in every browser.

On your spec questions

Updating the algorithm to use post-transform positions, or exposing transformed bounding boxes in the protocol, are reasonable feature requests — but they require a WebDriver spec change first, since Selenium can only consume what drivers return. Filing an issue against the W3C WebDriver spec (and the Selenium tracker referencing it) is the right venue; don't expect a client-side-only fix to be reliable.

Verification plan

1. Build a page with a reference element using transform: rotate(15deg) translateX(20px) and a target visually above it but not above the untransformed box.
2. Run above(ref) in Chrome, Firefox, and Edge with matched driver versions; log which element (if any) is returned.
3. Log the raw rect per browser (ref.getRect()) and compare with getBoundingClientRect() to see which drivers fold in the transform.
4. Repeat after resetting the transform; consistent results there confirm the transform is the divergence source.

One diagnostic detail that would sharpen this: the actual getRect() values per browser from your failing case — they'd show immediately whether the drivers disagree on the rect or on the locator math.