Build1 publisher2 min readPublished
CSS anchor positioning hands dropdown placement from Floating UI to the browser
CSS anchor positioning reached Baseline in September 2026, so current releases of every major browser can tether a dropdown to its trigger in CSS alone. Teams can retire Floating UI from simple dropdowns now if they plan what users on older browser versions will see.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Baseline lists the feature as newly available: current releases of every major browser support it, while older installs still do not.
- When the preferred placement would push the panel off screen, position-try-fallbacks has the browser try the next listed option, flipping vertically, horizontally, or both.
- Frutjam pairs anchor positioning with the HTML popover attribute and @starting-style to ship a dropdown with no JavaScript on the page.
- Placement values such as block-start and span-inline-end are logical directions, so an inline-start popover moves to the right side in Arabic or Hebrew layouts.
- Where anchor positioning is unavailable, Frutjam's panel drops back to the static position it would have in normal flow near its trigger, untethered.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Right-to-left support stops requiring a second set of pixel rules under [dir="rtl"] that someone has to remember to write and maintain.
- capability Libraries that built on anchor positioning before Baseline, as Frutjam did, now reach every current browser with code that is already in place.
- exposure Teams with users on older browser installs now maintain two placements per dropdown, tethered and fallback, and both have to be checked in every layout the menu appears in.
Popper.js and then Floating UI existed almost entirely to measure two rectangles and rewrite top and left on every scroll and resize, according to the post on dev.to [14]. Its Floating UI example shows what that work looks like. The code wraps computePosition in autoUpdate and asks for bottom-end placement with offset(8), flip() and shift({ padding: 8 }) [7]. It copies the returned x and y into the panel's style, and someone has to call cleanup() when the panel closes [7]. The post lists the cost as "a dependency, a listener on every scrollable ancestor, a layout read and a style write on every frame, and a teardown function" that someone has to remember [8].
According to the post, the CSS version does the same job with no bytes shipped and nothing to clean up [16]. That count covers script. The declarations themselves still travel in the stylesheet [4]. On the same-job claim, the two snippets disagree. Floating UI is asked for an 8px gap and a shift with 8px of padding, and the CSS example declares neither [17]. The post describes fallbacks as flips only, vertical, horizontal or both, and shows no CSS counterpart to shift [6].
Frutjam's own implementation is careful work. The trigger utility sets anchor-name from a custom property. The panel utility reads position-anchor, position-area and position-try-fallbacks the same way, defaulting to block-end span-inline-end and to none [9]. Twelve placement classes each set the area in one line [11]. With that default of none, a Frutjam popover does not flip unless a class or the page sets the try variable [9].
The degradation path depends on a second feature. Escape handling, outside-click close and rendering above the page without a z-index all come from the popover attribute [10]. Frutjam's fallback keeps those behaviours and loses only the tether [1]. The clean fallback the post describes therefore covers browsers that support popover but lack anchor positioning [15].
For plain menus that only need a flip, I think dropping the library now is the right call [6]. Where a design depends on shift or an exact offset [17], or where a large share of users run older browser versions [3], I'd keep Floating UI on those components.
What to watch
- A native CSS counterpart to Floating UI's shift middleware would let menus that slide along the viewport edge drop the library as well.
- The traffic share on browser versions released before anchor positioning shipped decides how many users see untethered fallback panels.
- How Floating UI's maintainers respond to Baseline, for example by documenting when native anchor positioning should replace the library.