CSS Anchor Positioning: Browser Support, Features, Issues

What is CSS Anchor Positioning?

CSS Anchor Positioning is a W3C CSSWG module that lets one element act as an anchor and another element size and position itself against that anchor in pure CSS. The entry points are the anchor-name and position-anchor properties plus the anchor() and anchor-size() functions.

Which browsers does CSS Anchor Positioning support?

CSS Anchor Positioning now ships by default in every major engine. Coverage hardened across late Chromium and Firefox builds, plus Safari 26 on Apple devices.

What are the key features of CSS Anchor Positioning?

The module ships a small property and function set that replaces several JavaScript layout patterns. Each piece composes with regular CSS positioning, so layouts stay declarative.

• anchor-name and position-anchor: Pair an anchor element with a positioned target through a single dashed-ident identifier, with no DOM walking or ResizeObserver glue.
• anchor() function: Read the inset edges of an anchor and pin a target's top, right, bottom, or left to any side of that anchor.
• anchor-size() function: Size the target to match the width, height, or any inset of the anchor, which keeps tooltips and popovers in proportion.
• position-area property: Place the target inside a 9-cell grid around the anchor through keywords like top center or bottom right, so authors skip pixel math.
• position-try-fallbacks and @position-try: Define a list of fallback positions that the browser tries when the primary placement overflows the viewport, replacing manual collision logic.
• position-visibility: Hide the target automatically when the anchor scrolls off screen or out of its containing block, useful for menu and tooltip cleanup.
• Top-layer integration: anchor() resolves from elements promoted to the top layer through popover or dialog, so menus stay accurate even after open() or showPopover().

What are the use cases of CSS Anchor Positioning?

Anchor Positioning collapses the JavaScript that used to drive overlays, menus, and field labels. The same CSS handles desktop and mobile placement without extra observers.

• Tooltips and info bubbles: Pin a tooltip to its trigger button with anchor() and let position-try-fallbacks flip the bubble to the opposite side when the viewport runs out of room.
• Popover menus and submenus: Anchor a popover to its toggle so the menu stays glued to the button when the user scrolls, resizes, or rotates the device.
• Form field labels and validators: Float validation messages next to the input that fired them, even when the input sits inside a scrollable form section.
• Custom select dropdowns: Build select widgets that place the option list under the trigger and flip above when the bottom of the page is near.
• Connector lines and callouts: Compute callout endpoints with anchor() and anchor-size(), so SVG and CSS lines track the anchor without ResizeObserver math.
• Settings dialogs and tour overlays: Tether on-page hints to the feature they explain, which keeps the hint visible as the user scrolls a long page.
• Dynamic chart labels and footnotes: Bind a label to a data point, an axis tick, or a footnote marker, and let the label flow with layout changes.

How do you check if a browser supports CSS Anchor Positioning?

CSS exposes a one-line @supports gate, and JavaScript exposes feature detection through CSS.supports(). Both run inside the browser with no build step.

• Open DevTools console: Press F12 or right-click the page and choose Inspect, then switch to the Console tab.
• Run the @supports check: Paste CSS.supports("anchor-name: --foo") into the console and press Enter. A return value of true means the browser parses anchor-name.
• Probe position-anchor: Run CSS.supports("position-anchor: --foo") to confirm the target side of the API works in the same browser build.
• Test the anchor() function: Run CSS.supports("top: anchor(bottom)") to confirm the function is wired up; older builds parse anchor-name but not anchor().
• Wrap your styles in @supports: Add @supports (anchor-name: --x) and (position-anchor: --x) so unsupported browsers fall back to the legacy positioning code.
• Run the snippet below: Paste it into the console or ship it inside your page to log a single ready or not-ready line.

function checkAnchorPositioning() {
    const parsesAnchorName = CSS.supports("anchor-name: --tip");
    const parsesPositionAnchor = CSS.supports("position-anchor: --tip");
    const parsesAnchorFunc = CSS.supports("top: anchor(bottom)");

    if (parsesAnchorName && parsesPositionAnchor && parsesAnchorFunc) {
        console.log("CSS Anchor Positioning is ready in this browser.");
        return true;
    }
    console.log("CSS Anchor Positioning is not fully available. Load the polyfill or fall back to absolute positioning.");
    return false;
}

checkAnchorPositioning();

If only anchor-name returns true but anchor() returns false, the browser is on a transitional Chromium build with the property parser ahead of the function. Use the polyfill on those builds.

What are the known issues with CSS Anchor Positioning?

CSS Anchor Positioning is the youngest module in the layout family, and the rough edges show up around older browser builds, polyfill gaps, and a couple of evolving syntax decisions.

• Apple devices on older OS releases miss it: Safari 26 added support, but iPhones on iOS 25, iPads on iPadOS 25, and Macs on macOS Sonoma or earlier do not ship it, even after Safari updates.
• Polyfill is partial: The Oddbird CSS Anchor Positioning polyfill covers anchor() and the basic anchor-name binding, but it does not implement every position-area, position-try-fallbacks, or anchor-size() detail.
• Syntax churn during rollout: Chrome 125 originally shipped inset-area and position-try-options; Chrome 129 renamed them to position-area and position-try-fallbacks, so older blog posts point at obsolete names.
• Top-layer interaction is order-sensitive: anchor() from a popover only resolves when the anchor element shares the containing block; nested popovers can lose the binding and render at the viewport origin.
• No DevTools picker yet: Chrome and Firefox DevTools surface anchor() values inside Computed Styles, but neither has a click-to-anchor helper, so debugging fall-through fallbacks still means scrolling Console output.
• Test runners may need a flag: Headless Chromium versions earlier than 125 still need the --enable-blink-features=CSSAnchorPositioning switch, which trips up CI pipelines pinned to older Chrome for Testing builds.
• Mobile WebView lag: Android WebView and iOS WKWebView track their host engine, so hybrid apps inherit the engine's gap; an Android 13 WebView on Chromium 120 has zero anchor-positioning support.

In my experience, the trickiest production failure is shipping a tooltip that flips correctly in Chrome 125 yet collapses to viewport (0, 0) in a slightly older Edge build because position-try-options was renamed to position-try-fallbacks. Detect both names with CSS.supports() before you trust either.

Citations

All CSS Anchor Positioning version numbers and platform notes in this guide come from these primary sources:

• W3C CSS Anchor Positioning Module Level 1: w3.org/TR/css-anchor-position-1
• CSSWG Editor's Draft: drafts.csswg.org/css-anchor-position-1
• MDN Web Docs - CSS anchor positioning module: developer.mozilla.org/en-US/docs/Web/CSS/CSS_anchor_positioning
• MDN Web Docs - Using CSS anchor positioning: developer.mozilla.org/en-US/docs/Web/CSS/Guides/Anchor_positioning/Using
• MDN Web Docs - position-anchor property: developer.mozilla.org/en-US/docs/Web/CSS/position-anchor
• MDN Web Docs - anchor() function: developer.mozilla.org/en-US/docs/Web/CSS/anchor
• Chrome for Developers - Introducing the CSS anchor positioning API: developer.chrome.com/blog/anchor-positioning-api
• Chrome for Developers - The CSS anchor positioning API docs: developer.chrome.com/docs/css-ui/anchor-positioning-api
• web.dev - Anchor positioning learn module: web.dev/learn/css/anchor-positioning
• Chrome Platform Status - CSS anchor positioning: chromestatus.com/feature/5166877531766784