Firefox 147 shipped CSS Anchor Positioning in early 2026, and with that, the last of the four core browser engines had implemented it. That single release tipped CSS Anchor Positioning into Baseline 2026 status — the point at which a web platform feature is considered safe to ship in production because it works across current stable versions of Chrome, Edge, Firefox, and Safari, on desktop and mobile. For anyone who has ever reached for Floating UI, Popper.js, or Tippy.js to keep a tooltip from clipping off the edge of the viewport, this is the quiet end of an era: the browser can now do that math itself.
What CSS Anchor Positioning actually replaces
The problem CSS Anchor Positioning solves is old and familiar to anyone who has built a design system. You have a trigger element — a button, an icon, an input — and you need a second element, a tooltip, a dropdown menu, a popover, to appear next to it. Simple enough until the trigger is near the edge of the screen, or the page scrolls, or the viewport resizes, or the floating element is bigger than the available space in the direction you wanted it to open. Solving that correctly means calculating coordinates, detecting viewport boundaries, flipping the placement when there's no room, and repositioning on every scroll and resize event, all while doing it fast enough that the UI doesn't stutter.
CSS could never do this natively, so the entire ecosystem outsourced the problem to JavaScript. Popper.js became the de facto standard for years, was eventually succeeded by Floating UI (built by largely the same team), and Tippy.js wrapped that positioning logic in a ready-made tooltip component. Nearly every component library — design systems, UI kits, admin dashboards — has one of these three sitting somewhere in its dependency tree, often several layers deep as a transitive dependency of some other UI package.
That dependency has a real cost that's easy to stop noticing because it's been there so long. It's bundle size shipped to every user regardless of whether their browser needs it. It's runtime JavaScript recalculating positions on scroll and resize listeners, work that now competes with everything else on the main thread. It's another package to keep patched, another license to track, another maintainer's judgment call you're implicitly trusting every time you run npm install. None of that is a case against these libraries — they solved a real problem well, for a long time. It's a case for asking, now that the platform does the same job, whether you still need the dependency at all.
How CSS Anchor Positioning actually works
The mechanism is a small set of CSS additions that talk to each other. First, you mark an element as an anchor by giving it a name:
.trigger {
anchor-name: --my-anchor;
}Then, on the element you want positioned relative to that anchor, you point at it and place it using the anchor() function inside standard positioning properties:
.tooltip {
position: absolute;
position-anchor: --my-anchor;
top: anchor(bottom);
left: anchor(center);
}That's the entire relationship, expressed without a single line of JavaScript: the tooltip knows which element is its anchor, and anchor() lets it reference that anchor's edges and center directly inside its own top, left, right, and bottom values. No measuring, no event listeners, no manual recalculation.
The part that replaces the hardest piece of what Floating UI and Popper.js do — flipping placement when there isn't room — is position-try-fallbacks. You declare a preferred position and a list of fallback positions, and the browser tries each one in order until it finds one that fits inside the viewport, all without a single JavaScript event handler:
.tooltip {
position-try-fallbacks: flip-block, flip-inline;
}The browser evaluates whether the default placement overflows, and if it does, tries the listed fallbacks in sequence. That's the automatic edge-detection-and-reposition logic that used to be the entire reason to install a positioning library, now expressed as a CSS declaration.
CSS Anchor Positioning is also designed to work alongside the HTML Popover API rather than as a competing feature. The Popover API already handles the accessibility plumbing for disclosure widgets — focus management, Esc-to-dismiss, top-layer rendering so a popover isn't clipped by an ancestor's overflow: hidden, and the right ARIA relationships when it's set up correctly. Anchor positioning slots into that as the layout mechanism: the Popover API decides when and whether something is shown and how it behaves for assistive technology, and CSS Anchor Positioning decides where it appears on screen. For tooltips, dropdowns, and popovers specifically, that combination covers most of what a positioning library plus a component wrapper used to handle jointly.
Baseline 2026, Firefox, and what actually changed
It's worth being precise about why this specific release mattered. Chrome and Edge shipped CSS Anchor Positioning back in version 125, in 2024. Safari followed with Safari 26 in 2025. Firefox was the holdout, and it didn't ship support until Firefox 147, in early 2026. That gap is exactly why this feature is only reaching Baseline 2026 status now rather than a year or two earlier — Baseline isn't awarded the moment one or two engines ship something; it requires the current stable versions of Chrome, Edge, Firefox, and Safari to all support it. Firefox catching up is what completed that set.
The Baseline 2026 designation for CSS Anchor Positioning reflects roughly 91% global browser coverage across Chromium, Firefox, and Safari engines — a threshold generally treated as high enough to ship without a polyfill for most production contexts. That's not "100% of every browser anyone has ever used," and it's worth checking your own traffic rather than assuming the global number maps exactly onto your audience. But it's a materially different situation than shipping a feature that only works in one engine family, which is the situation Floating UI and Popper.js were originally built to paper over.
CSS Anchor Positioning isn't reaching this milestone in isolation, either. It's landing in roughly the same window as @scope, which lets you write CSS that's scoped to a specific subtree without reaching for CSS-in-JS or naming conventions, and which Firefox 146 joined shortly before anchor positioning arrived; container queries, which let components respond to their container's size rather than the viewport; and the :has() pseudo-class, which finally gives CSS a way to select a parent based on its children. None of those get the deep-dive here, but they're part of the same broader pattern worth noticing: a wave of CSS features landing in 2026 that each independently reduce the amount of JavaScript needed to build things that used to require it.
Should you actually remove Floating UI or Popper.js right now
This is the question every team maintaining a component library is going to ask, and the honest answer is: it depends on what "right now" means for your codebase, and it's a different answer for new work than for existing production code.
For new projects starting today, there's reportedly no technical reason to install Floating UI, Popper.js, or Tippy.js for basic anchored positioning. If you're building a new component library, a new design system, or a new tooltip and dropdown implementation from scratch in 2026, reach for anchor-name, position-anchor, anchor(), and position-try-fallbacks first, paired with the Popover API for the disclosure behavior. You'll get equivalent or better positioning behavior with a smaller bundle and no runtime scroll/resize listeners doing the recalculation for you.
For existing production applications, ripping out a positioning library that's already working is a different calculation, and it's usually not urgent. If Floating UI or Popper.js is deeply embedded in a mature component library that's shipping fine today, the migration cost — auditing every call site, verifying edge cases, testing across your actual supported browser matrix, updating any custom positioning logic built on top of the library's API — has to be weighed against a benefit that's mostly about future maintenance burden rather than a current production problem. A pragmatic middle path: stop reaching for these libraries in new components starting now, and treat migrating existing components as an opportunistic cleanup — something you do when you're already touching that component for another reason, not a dedicated project you schedule this quarter. Where these libraries genuinely earn their keep long-term is in complex cases with deep customization needs or a real requirement to support older browser versions that predate Baseline 2026 support — that's a legitimate reason to keep the dependency around rather than a reason to avoid the native approach everywhere.
Practical takeaways
Check your actual traffic against caniuse-style browser support data before assuming Baseline 2026 coverage matches your audience — global averages are a starting point, not a guarantee for your specific user base. For progressive enhancement, @supports (anchor-name: --a) lets you detect support and provide a JavaScript-based or simplified static fallback for the small remaining slice of older browsers, so you're not choosing between "native only" and "library only" as an all-or-nothing decision. Pair anchor positioning with the HTML Popover API rather than reinventing disclosure behavior yourself — it already handles the focus management, dismissal, and top-layer rendering that accessible tooltips and dropdowns depend on, and reinventing that logic in raw JavaScript is a worse trade than keeping a library for it. Start every new tooltip, dropdown, or popover component with the native CSS approach, and reserve Floating UI or Popper.js for existing components you're not actively rewriting, or for genuinely complex positioning needs the native APIs don't yet cover. And revisit this periodically — Baseline coverage only grows over time, and a browser version you're excluding today may not need excluding in six months.
CSS Anchor Positioning reaching Baseline 2026 doesn't mean every project needs an emergency dependency audit this week. It means the calculus for new work has genuinely shifted: the browser now handles a category of layout problem that used to require a JavaScript library, runtime event listeners, and a chunk of your bundle, and it does it with less code and less maintenance surface than the alternative it's replacing. Treat it the way you'd treat any other Baseline milestone — as a green light for what you build next, not a mandate to rewrite what already works.