You shipped a tooltip last year and it dragged in Floating UI, a positioning hook, and a ref you had to thread through three components. In 2026 the browser does that job for free, and most of the reasons people still reach for JavaScript are out of date. Here are seven myths about CSS anchor positioning, and what's actually true.
Myth: You still need a JS library to position a tooltip
Reality: Anchor positioning tethers one element to another in pure CSS — the exact job Floating UI and Popper.js were built for. You name an anchor, point a positioned element at it, and pick a side.
.button {
anchor-name: --trigger;
}
.tooltip {
position: absolute;
position-anchor: --trigger;
position-area: top;
}No refs, no measuring, no resize listeners. The browser recomputes on scroll and layout changes for you.
Myth: It doesn't work in real browsers yet
Reality: It crossed into Baseline. Chrome and Edge shipped it in 125, Safari in 26.0 (September 2025), and Firefox enabled it by default in 147 on January 13, 2026. That's roughly 83% of global users as of April 2026 — the same ballpark where you'd already ship a modern feature with a fallback.
If you'd use
:has()in production today, anchor positioning is in the same support tier.
Myth: It's just position: absolute with extra words
Reality: position: absolute resolves against the nearest positioned ancestor. The anchor() function resolves against a different element entirely, even one that isn't an ancestor.
.tooltip {
position: absolute;
bottom: anchor(--trigger top);
left: anchor(--trigger left);
}That cross-container reference is the whole point: your tooltip can live at the end of the DOM (or in the top layer) and still track a button buried deep in the tree.
Myth: Handling off-screen flipping is a nightmare
Reality: That was the single biggest reason to keep the JS. Now position-try-fallbacks flips the element when it would overflow the viewport.
.tooltip {
position-area: top;
position-try-fallbacks: flip-block, flip-inline;
}Need custom behavior? Define named fallbacks and the browser tries them in order until one fits.
@position-try --shift-bottom {
position-area: bottom;
margin-top: 0.5rem;
}
.tooltip {
position-area: top;
position-try-fallbacks: --shift-bottom;
}Myth: You have to use the Popover API to use it
Reality: They're independent features that happen to pair beautifully. Anchor positioning works with any positioned element. The Popover API just gives you top-layer rendering and light-dismiss for free, so menus and tooltips escape overflow: hidden without a portal. Use one, both, or neither.
Myth: The anchor and target must be related in the DOM
Reality: There's no required parent, sibling, or ancestor relationship. Any element can reference any anchor whose anchor-name is visible in its scope. When names collide — think a list where every row has its own anchor — anchor-scope limits a name to a subtree so each target binds to the right one.
li {
anchor-scope: --row;
}Myth: There's no graceful degradation for older browsers
Reality: You have three layers of safety. Gate the enhancement with @supports, let position-visibility hide a tether when its anchor scrolls away, and reach for the official polyfill if a specific old browser matters.
@supports (anchor-name: --x) {
/* progressive enhancement here */
}The honest caveat: Safari 18.2–18.3 places anchored elements correctly but ignores @position-try, so flipping needs Safari 18.4+ or 26. Plan your fallback content, not a full JS reimplementation.
The takeaway: for tooltips, menus, and popovers, the default in 2026 is CSS first and JavaScript only when you hit a genuine edge case.