What Is CSS Anchor Positioning and How Do I Use It in Webflow Tooltips and Menus?

Why did I rip Tippy.js out of a Webflow site last Tuesday?

Last Tuesday in Bengaluru, I opened a Webflow project for a SaaS founder who hired me to fix a slow product page. The page used Tippy.js for tooltips and a custom Floating UI script for the mega menu. The Lighthouse performance score sat at 71 on mobile. I replaced both libraries with pure CSS Anchor Positioning. The score jumped to 92. According to Can I Use (June 2026), CSS Anchor Positioning now has Baseline 2025 status with over 88 percent global browser support. That means I can finally drop the JavaScript and let the browser do the work. In this post I will walk you through what it is, how I wire it into Webflow, and where I still keep a fallback.

What is CSS Anchor Positioning in plain words?

CSS Anchor Positioning is a browser feature that lets one element stick itself to another element using only CSS. You name an anchor with the anchor-name property, then point a popover, tooltip, or menu at it with position-anchor. The browser handles the math, the flips, and the edge cases. No JavaScript library required.

Before this shipped, I used Floating UI or Popper.js to calculate where a tooltip should sit relative to a button. Those libraries are clever but they cost bytes and CPU. With anchor positioning, the layout engine itself owns the logic. Chrome 134 shipped it widely in late 2024, Safari 18.2 followed in early 2025, and Firefox 138 closed the gap in spring 2026. MDN has solid reference docs if you want to go deeper after this article.

How do I add CSS Anchor Positioning to a Webflow project?

I add it through Webflow Custom Code as an embed, because the Webflow Designer does not expose anchor-name or position-anchor in the style panel yet. I drop an Embed block on the page, write a short style block, and assign IDs or classes to the trigger and the popover. That is the whole setup.

Here is the pattern I use. I give the trigger button an anchor name like anchor-name: --help-button in custom CSS. Then I give the tooltip element position-anchor: --help-button and use top: anchor(bottom) plus left: anchor(center). The tooltip parks itself under the button. If the user scrolls or resizes, the browser repositions it for free. I usually pair this with position-try-fallbacks so the tooltip flips above the button when there is no room below.

How does this compare to Floating UI, Popper.js, and Tippy.js?

The honest answer is that Floating UI and Tippy.js still win when you need rich interactions, animation chains, or support for browsers older than 2024. For everything else, native CSS wins on weight and speed. My measured bundle for the SaaS client dropped from around 35KB of minified JavaScript to under 8KB of CSS plus a tiny progressive enhancement script.

Tippy.js is a wrapper around Popper.js, and Popper.js is the older sibling of Floating UI. All three do collision detection and auto-flipping. CSS Anchor Positioning does the same thing now, just in the rendering engine. I still reach for Floating UI when a client needs draggable popovers or virtual element anchoring, since the CSS spec does not cover those cases yet. For 80 percent of tooltips and menus I see in Webflow, anchor positioning is enough.

But what about users on older browsers, does this break for them?

It does not break if you write the fallback correctly. I always pair anchor positioning with a CSS feature query using @supports (anchor-name: --x). Inside the supports block, I use the new properties. Outside it, I keep a simple absolute position with sensible defaults. The tooltip still appears for everyone, it just sits in a fixed spot instead of being smart about edges.

For one of my clients, a legal services firm in Indiranagar, around 6 percent of their traffic still runs older Samsung Internet builds. I tested with Chrome DevTools device emulation and BrowserStack. The fallback looks plain but works. That is the deal I make with older browsers. They get function, not flair. Caniuse data from June 2026 confirms the holdouts are mostly older Android WebView and corporate Edge installs.

How do I wire it into a Webflow Components 2 setup?

I build the tooltip and the trigger inside a single Webflow Component so the structure travels with the design. I add a Custom Attribute on the trigger element, something like data-anchor="help-1", and another on the popover with data-popover-for="help-1". Then in a site-wide Custom Code embed, I run a tiny script that reads those attributes and applies the matching anchor-name and position-anchor values.

I do it this way because Webflow Components 2 lets marketing teams duplicate the component without my help, and each instance gets unique anchor names automatically. I also combine this with the native Popover API using the popover attribute on the popover element. That gives me free top-layer rendering, light dismiss on outside click, and keyboard escape. The Popover API and CSS Anchor Positioning were designed to work together, and they do.

How do I measure the win and prove it to clients?

I run Lighthouse before and after, and I check Total Blocking Time, Largest Contentful Paint, and the JavaScript transfer size in Chrome DevTools. For the SaaS founder I mentioned, Total Blocking Time dropped from 340ms to 90ms on a throttled mobile profile. Largest Contentful Paint moved from 2.8 seconds to 1.9 seconds. The Lighthouse performance score went from 71 to 92, a 21 point gain on the same hardware.

I share these numbers in a short Loom video for the client. Founders care about score deltas more than they care about the technique. I also pull the Network panel in Chrome DevTools and show them the missing Tippy.js request. Visual proof beats a paragraph of explanation. If you use Tailwind elsewhere, the same measurement loop applies. GSAP, which I sometimes keep for hero animations, is unaffected because it serves a different purpose.

What should I do this week to try this in Webflow?

Pick one small surface first. I suggest a help tooltip on a pricing page or a single dropdown in your nav. Open the Webflow Designer, add an Embed block, and paste a minimal style block that sets anchor-name on the trigger and position-anchor on the tooltip. Wrap the new properties in an @supports query so older browsers stay safe. Publish to a staging subdomain and run Lighthouse twice, once before and once after. Then audit the JavaScript bundle in Chrome DevTools and confirm Tippy.js or Floating UI is gone.

If you want to keep pushing native CSS in your Webflow stack, you might enjoy my walkthrough on using the CSS :has selector to replace combo classes, which pairs well with anchor positioning for cleaner component logic. And since the Popover API is the natural partner for this technique, take a look at my guide on the Popover API for Webflow menus and tooltips before you ship anything to production.

If you want a hand auditing your Webflow site, finding the slow tooltips, or rebuilding a mega menu without a JavaScript library, send me a note. I work with founders and marketing teams from Bengaluru, and I am happy to take a quick look at your current build and tell you what I would change first.