CSS anchor positioning: what it does, and why MDN still says limited availability

CSS anchor positioning lets you tether an absolutely positioned element to another element, so a tooltip follows its button without a line of JavaScript. It is genuinely elegant. It is also, according to MDN's own banner, not something you can ship unconditionally yet - and a lot of writing published in 2026 says otherwise.

The three pieces

The model is small. You name an element as an anchor, you point another element at that name, and you position against it.

.trigger {
  anchor-name: --my-trigger;
}

.tooltip {
  position: absolute;
  position-anchor: --my-trigger;
  top: anchor(bottom);
  left: anchor(left);
}

anchor-name registers the element under a custom identifier. position-anchor associates the positioned element with that identifier. The anchor() function then resolves to an edge of the anchor, so anchor(bottom) is the anchor's bottom edge expressed in the positioned element's coordinate space.

The part that makes it more than syntactic sugar is what happens near the edge of the viewport. A tooltip pinned below its trigger should flip above it rather than get clipped, and that flip is exactly the logic every positioning library exists to provide. Anchor positioning offers it declaratively through position-try fallbacks: you list alternative placements, and the browser picks the first that fits.

Why the enthusiasm outran the support

Chrome shipped anchor positioning in 2024, and a wave of posts followed announcing that native CSS had replaced tooltip libraries. Search for it in 2026 and you will find claims of Baseline status and coverage percentages in the nineties.

MDN's page for position-anchor currently carries a different banner: Limited availability, with the explanation that this feature is not Baseline because it does not work in some of the most widely-used browsers. That is the reference documentation for the property itself, and it is the line worth trusting when secondary sources disagree with it.

This is not a reason to ignore the feature. It is a reason to check the banner on MDN yourself, on the day you plan to ship, rather than inheriting a claim from an article that was optimistic when it was written.

How to use it without betting on it

Feature-query it. @supports is the difference between progressive enhancement and a broken layout for whoever is on the wrong engine:

.tooltip {
  /* fallback placement that works everywhere */
  position: absolute;
  top: 100%;
  left: 0;
}

@supports (anchor-name: --x) {
  .trigger { anchor-name: --my-trigger; }
  .tooltip {
    position-anchor: --my-trigger;
    top: anchor(bottom);
    left: anchor(left);
  }
}

Write the ordinary positioning first and let the anchored version override it inside the query. Browsers that understand anchoring get the good behaviour; the others get something that still works.

The honest summary of where this leaves you: anchor positioning is the right direction and worth learning now, but a production tooltip in 2026 still needs a path for engines that do not support it. Deleting the library outright is a decision to make from the compatibility table, not from a headline.

Where it fits with the rest of the platform

Anchor positioning pairs naturally with the Popover API, which handles the showing and dismissing while anchoring handles the placement, and with the dialog element for the cases that need a real modal. Those two are further along in support, which is part of why they are worth reaching for first.

The short version

anchor-name marks the anchor, position-anchor connects to it, anchor() resolves its edges, and position-try fallbacks handle the flip near a viewport edge. MDN lists the property as limited availability and explicitly not Baseline. Use it behind @supports, keep an ordinary fallback, and check the compatibility table on the day you ship rather than trusting a percentage from a blog post.