How to Use CSS Anchor Positioning for Tooltips in Webflow Sites in 2026

Floating UI ships about 23 million weekly downloads from npm for its core package alone. That is the JavaScript library most marketing sites use to position tooltips, dropdowns, and popovers. As of early 2026, almost none of that JavaScript is necessary for a typical Webflow site. CSS Anchor Positioning hit Baseline 2026 with full support across Chrome 125+, Firefox 132+, and Safari 18.2+, covering roughly 91 percent of browser traffic. This tutorial walks through the exact pattern I now use to add anchor-positioned tooltips to Webflow client sites, the cases where it works flawlessly, and the rare cases where I still reach for JavaScript.

What Is CSS Anchor Positioning, and What Problem Does It Solve?

CSS Anchor Positioning is a browser-native API that lets an absolutely-positioned element tether to another element on the page using only CSS. The anchor element gets an anchor-name property. The positioned element gets a position-anchor property pointing back to that name. The positioned element then uses the anchor() function or the position-area property to place itself relative to the anchor. No scroll listeners. No resize observers. No JavaScript at all for the positioning logic.

The problem this solves is the one every marketing site has shipped a JavaScript fix for. A tooltip or dropdown that needs to stay attached to its trigger button when the page scrolls, when the viewport resizes, or when the trigger moves due to layout shift. Floating UI and Popper.js exist because CSS could not do this. With Anchor Positioning, CSS can. The browser handles the math, the positioning, and the viewport-edge fallback automatically.

What Does Browser Support Look Like in May 2026?

Chrome and Edge have shipped full support since version 125. Firefox landed full support in version 132. Safari supports the core anchor() function and position-anchor since version 18.2, with the at-rule position-try-fallbacks landing in 18.4. As of early 2026, that combined coverage reaches roughly 91 percent of global browser traffic, with the long tail being older Safari and Firefox versions and a small share of legacy mobile browsers.

For a Webflow site serving B2B SaaS clients in North America and Europe, the practical coverage is closer to 95 percent. For a consumer site with significant tail coverage, the right pattern is progressive enhancement. The anchor positioning works for the 95 percent. The 5 percent on older browsers see a graceful fallback that uses the older absolute positioning approach. Both groups get a usable interface. The tutorial below assumes the modern path with a fallback noted in the appropriate section.

How Do I Add an Anchor and a Positioned Element to a Webflow Site?

Webflow handles anchor positioning through Custom Code embeds because the Designer's style panel does not yet expose the anchor-name and position-anchor properties as native controls. The pattern is to give the trigger element a class like info-button and the tooltip element a class like info-tooltip, then add a Custom Code embed with the Anchor Positioning CSS that targets those classes.

The minimum CSS is short. The info-button class gets anchor-name set to a dashed-ident value like double-dash help-trigger. The info-tooltip class gets position-anchor set to the same dashed-ident, position set to fixed, and a position-area declaration like top center to place the tooltip above the button. Three rules, no JavaScript, and the tooltip stays attached to the button across scroll, resize, and Webflow's own page transitions. I covered the upstream component discipline in my component-scoped Interactions tutorial.

What Does the Position-Area Property Actually Do?

The position-area property places the positioned element in one of sixteen logical positions relative to the anchor. Common values include top, bottom, left, right, top start, bottom end, and the longer compound forms like top span-all that span across the anchor's full width. The property reads naturally because the keywords describe where the tooltip sits relative to the trigger.

For a typical tooltip, position-area: top center places the tooltip above the trigger, centered horizontally. position-area: bottom right places it to the lower-right corner. The property handles RTL languages automatically through its use of logical properties like block-start and inline-end, which is a meaningful win for Webflow sites with multilingual setups. I covered the related localization work in my Webflow Localization tutorial.

How Do I Handle Tooltips That Would Run Off the Edge of the Screen?

The position-try-fallbacks property tells the browser to try alternative positions when the default position would cause the tooltip to overflow the viewport. Common fallback values include flip-block to flip the tooltip from top to bottom or vice versa, and flip-inline to flip from left to right. Combining them as flip-block flip-inline gives the browser permission to flip on either axis, with a small preference for the original position when it fits.

The behavior is genuinely automatic. The browser measures viewport edges, evaluates the fallback list, and renders the first option that fits. If none fit, the browser chooses the least-bad option. For a Webflow site with tooltips appearing throughout a long scrollable page, this means tooltips near the top of the page render below their trigger and tooltips near the bottom render above, without the studio writing any logic to handle the boundary cases.

How Do I Pair Anchor Positioning With the HTML Popover API?

The Popover API and Anchor Positioning are complementary rather than overlapping. The Popover API handles show, hide, light-dismiss, and top-layer stacking. Anchor Positioning handles where the popover sits when it appears. Combining them gives a fully accessible tooltip pattern with zero JavaScript.

The HTML pattern uses the popovertarget attribute on the trigger button, pointing to the popover element's id, and the popover attribute on the tooltip element. When a popover is associated with a button this way, the browser creates an implicit anchor reference. The CSS then uses position-anchor and position-area as before. The result is a tooltip that opens on click, dismisses on outside-click, traps focus correctly for accessibility, and stays positioned relative to the trigger across all interactions. The combination is what makes Floating UI's 23 million weekly downloads largely unnecessary for marketing-site work in 2026.

What Does the Webflow Custom Code Embed Look Like?

The embed has three parts. An HTML chunk with the trigger button and the tooltip element marked up with popovertarget, popover, and id attributes. A CSS chunk with the anchor-name on the trigger, position-anchor and position-area on the tooltip, plus the popover-open state styling. An optional CSS chunk for entry and exit animation using @starting-style and the allow-discrete transition behavior, which makes the tooltip animate in and out smoothly rather than appearing and disappearing instantly.

For a Webflow site, the embed lives inside an Embed element in the Designer, scoped to the section that contains the tooltips. Total embed length is around 30 lines including the entry animation. No external scripts, no library dependencies, no maintenance burden when a library version drifts. The embed reads as quickly as a traditional CSS class definition because that is essentially what it is, just with a few new property names.

What About Hover-Triggered Tooltips Specifically?

Hover-triggered tooltips are the one case where Anchor Positioning by itself is not yet enough. The popover attribute supports a value of hint that is designed for hover and focus, but as of May 2026 the popover-hint variant has limited browser support. The compatible alternative for hover-triggered tooltips is to keep the JavaScript layer minimal, using a small show-on-hover handler that sets the popover open state, while letting CSS handle all the positioning.

The result is roughly 10 lines of JavaScript instead of the 200-plus that a Floating UI integration typically required. The win is still substantial. For Webflow Partners building accessible UI, the practical advice is to use click-triggered popovers for the majority of cases, reserving hover for genuinely necessary tooltips like form-field help text, and keeping the hover handler to the smallest possible footprint. The Interest Invoker API with interesttarget attributes is in early development and will eventually close this gap entirely, but it is not yet broadly supported.

How Does This Compare to Webflow's Built-In Interactions System?

Webflow Interactions handle on-click and on-hover state changes using the platform's animation timeline. They do not handle anchor-relative positioning. The two systems coexist cleanly. Use Webflow Interactions for the visual transition (opacity, transform, scale). Use Anchor Positioning CSS for the positioning logic. The combination gives the visual polish of Webflow's Interactions with the layout reliability of native CSS.

For studios already heavy on Webflow Interactions, this means existing tooltip patterns can upgrade in place. Replace the JavaScript positioning logic with an Anchor Positioning CSS embed. Keep the Webflow Interactions animation. The visual result is identical or better. The maintenance burden drops because the JavaScript layer is gone. I covered the Interactions discipline in my scroll-triggered animations Chrome 145 piece, which uses related browser-native CSS features.

What Is the One Production Concern I Watch For?

The one concern is the older Safari long tail. Safari 18.2 has the basics. Safari 18.4 and later have the position-try-fallbacks at-rule that handles viewport-edge cases. For Webflow sites with significant Safari user share that includes pre-18.4 versions, tooltips near the viewport edge can render off-screen until the user scrolls. The fix is to add a small fallback inside an @supports rule, or to keep edge-case tooltips away from the viewport boundaries by design.

For most B2B SaaS Webflow sites the issue is invisible because the active Safari user share has moved to recent versions. For consumer sites with broader device coverage, a brief manual test on the older Safari versions, plus a position-area choice that avoids viewport edges, handles the issue without engineering work. The trade-off is acceptable given the alternative was Floating UI plus its full bundle and maintenance overhead. The CSS Anchor Positioning specification is stable, well-supported, and production-ready for the vast majority of Webflow client work in 2026. For new projects there is no longer a reason to default to a JavaScript positioning library.

If you are running a Webflow practice and want to migrate one client site off Floating UI to native CSS Anchor Positioning this week, drop me a line and tell me which page has the most tooltip-heavy interface today. Let's chat.