Because until recently CSS had no way to say "put this element next to that one". Developers had to measure both elements in JavaScript, do the math, and redo it on every scroll and resize. CSS anchor positioning finally moves that job into the browser, where it belongs.
Anyone who has built a dropdown menu, a tooltip, or a date picker knows the pain. The element looks perfect until someone opens it near the bottom of the screen, and then it hangs off the edge. The usual fix is a JavaScript library that watches the viewport and flips the element to the other side. It works, and it costs you a dependency, a bundle, and a small performance tax on every scroll event.
That whole category of problem now has a native answer, and as of this year every major browser engine ships it. This is one of the bigger practical changes to front-end layout in a while, so it is worth understanding properly before you rip anything out.
CSS anchor positioning is a CSS module that lets you tether one element to another. You mark an element as an anchor, then tell a second element to position itself relative to that anchor. The browser handles the measurement, the placement, and the fallback when there is not enough room.
MDN describes it as a way to define anchor elements and anchor-positioned elements, where the positioned element takes its size and location from the anchor. The key insight is that the two elements do not need to be near each other in the HTML. They can sit anywhere in the document and still be visually tied together.
That last part is what makes it genuinely new. Before this, tying two elements together visually usually meant nesting them, which forced your HTML structure to serve your visual design. Anchor positioning breaks that link, so you can write markup that makes sense semantically and still get the layout you wanted.
All three major engines now do. Chrome shipped it first, with the Chrome for Developers blog stating that "anchor positioning is available from Chrome 125" in a post published in May 2024. Safari followed in Safari 26.0, announced by WebKit in September 2025. Firefox added support in Firefox 147, released on 13 January 2026.
That timeline matters for how you plan work. Chrome and Edge users have had this for roughly two years. Safari users got it in late 2025. Firefox users only got it in January of this year, which means a meaningful number of people are still on Firefox builds that do not have it.
The WebKit announcement is worth reading if you support Safari, because it notes that anchor positioning "pairs well with the popover attribute (which shipped in Safari 17.0)". Those two features were designed to work together, and using them separately is a bit like buying half a tool.
Support arriving in every engine is the moment a feature becomes safe to plan around rather than experiment with. We track this the same way for every new capability, using the approach we described in our piece on Baseline web features.
You give the anchor element a name with the anchor-name property, then point a second element at that name using position-anchor. From there you place the second element with either the position-area property, which uses a simple grid of positions around the anchor, or the anchor function for precise control.
The position-area approach is the one most teams will use. You describe where you want the element in plain terms, such as the area above the anchor or to its inline end, and the browser works out the coordinates. It reads almost like the sentence you would say out loud in a design review.
The anchor function is the precise version. It lets you reference a specific edge of the anchor, so you can write a rule that sets an element's top to the anchor's bottom edge. There is also an anchor-size function that sizes the positioned element from the anchor's dimensions, which is how you make a dropdown exactly as wide as the button that opened it.
MDN also documents anchor-scope, which controls which anchors a given element can see. That one becomes important on a page with many repeated components, where every card has its own button and its own menu and you do not want them tangling.
The position-try family is the part that replaces most of your JavaScript. It lets you declare backup positions, so when the preferred placement would overflow the screen, the browser automatically tries the next one. That is the flip behavior every tooltip library implements by hand, done natively.
You write your ideal position first, then list fallbacks through position-try-fallbacks, with position-try-order controlling how the browser works through them. There is also a position-try shorthand that combines them, and an at-rule called position-try for defining named alternative positions you can reuse.
Alongside it sits position-visibility, which tells the browser to hide the positioned element under certain conditions. The obvious case is a tooltip whose anchor has scrolled out of view inside a scrollable panel. Without this, the tooltip floats in space pointing at nothing.
Together these turn a genuinely fiddly problem into declarative CSS. In our experience this is where the real time saving is, because the fallback logic was always the part that broke on the third device someone tested.
For most common cases, yes. Tooltips, dropdown menus, and simple popovers can now be built with CSS alone. Libraries like Floating UI still earn their place for complex behavior such as virtual anchors, arrow elements that track the anchor, or interaction logic that goes beyond placement.
Our honest take is that most marketing sites and product sites never needed the full power of those libraries. They needed a menu that opens below a button and flips up when it runs out of room. That is now a handful of CSS lines, and dropping the library is a real performance win because it removes both the download and the scroll listeners.
Where we would keep the library is in application interfaces with dense, interactive components. If your positioned element needs to follow a cursor, attach to an arbitrary coordinate, or coordinate with a focus management system, a purpose-built library is still the sane choice. Use the platform where the platform is enough, and reach for the dependency where it is not.
They solve two halves of the same problem. The Popover API handles the behavior, meaning the element sits in the top layer, closes on Escape, and manages light dismiss without custom code. Anchor positioning handles where it appears. Used together you get a complete menu or tooltip with no JavaScript at all.
WebKit made this pairing explicit in the Safari 26.0 announcement, describing anchor positioning as something that pairs well with the popover attribute and makes it easy to create responsive menus and tooltips. That is a strong signal about intended use, and it is how we would build these components on a new project.
We covered the behavior side separately in our guide to the Popover API. Read the two together, because neither is as useful on its own.
The positioned element falls back to normal CSS positioning, which usually means it appears somewhere unhelpful rather than not at all. That makes a sensible default position essential. Write your CSS so the element is still usable without anchor positioning, then let anchor positioning improve it.
The practical pattern is to position the element reasonably with standard absolute positioning first, then apply the anchor properties. Browsers that understand them will use them. Browsers that do not will ignore the unknown properties and keep your fallback. You can also wrap the enhancement in a feature query so it only applies where supported.
This is ordinary progressive enhancement, and it is the same discipline that makes every other new CSS feature safe to adopt early. We wrote about the general method in our piece on progressive enhancement.
Yes, as an enhancement, and with a working fallback underneath. Every major engine supports it, but Firefox only shipped it in January 2026, so a share of real visitors will still be on versions without it. Build the component so it works either way and you get the benefit with no risk.
The one place we would be more cautious is a build where the positioned element carries critical information, such as a validation message on a checkout form. If a fallback position could obscure the field it describes, test that state properly on older builds before shipping. Everything else, including menus, tooltips, and hover cards, is low risk.
On a Webflow build this lands as custom code rather than a Designer setting, so it belongs in a site-wide stylesheet with a clear comment explaining what it does. Anyone editing the site in two years needs to understand why those properties are there.
Pick one component you already ship, ideally a dropdown or tooltip that currently relies on a JavaScript library, and rebuild it with position-anchor, position-area, and position-try. Measure the bundle before and after. That single experiment tells you more about whether this is worth adopting than any article can.
The wider point is that the platform keeps absorbing things we used to install. Container queries, the Popover API, and now anchor positioning have all replaced dependencies that felt permanent a few years ago. Every one you remove makes a site faster and easier to maintain, which is most of what a good build is.
If you want a hand working out which parts of your front end could go native, or you would like us to look at a site that feels heavier than it should, let's talk. We're happy to walk through it with you at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.