Are Anchor Positioning Tooltips Now Safe to Ship in Webflow?

CSS anchor positioning is one of the most-requested Webflow design patterns I have seen from B2B SaaS clients in 2026, usually for pricing-page tooltips, sticky CTAs, and dropdown menus that attach to a moving anchor element. Chrome has supported the spec since Chrome 125 in May 2024, but Safari only reached parity on May 11, 2026 when Safari 26.5 shipped three bug fixes for chains of three or more anchored elements, anchor() fallback unitless zero, and display:contents anchor-scope behavior. From Phoenix Studio in Bengaluru, I deferred shipping an anchor-positioned tooltip pattern on a real B2B SaaS pricing page in late April because of the exact chains-of-three bug Safari 26.5 fixed. The pattern is now safe to ship. In this piece I cover what anchor positioning is, what Safari 26.5 fixed, and the Webflow build pattern I am sending to that client this week.

What is CSS anchor positioning?

CSS anchor positioning is a web platform feature that lets one element position itself relative to another element (the anchor) without requiring JavaScript or hardcoded coordinates. The feature uses the anchor-name property on the anchor element and the position-anchor and anchor() value functions on the positioned element. The pattern enables tooltips, dropdowns, sticky CTAs, and floating UI patterns to track a moving reference element automatically.

For Webflow B2B SaaS marketing sites, anchor positioning replaces a category of JavaScript-driven positioning patterns that previously required custom scripts or libraries like Popper.js or Floating UI. The CSS-native approach reduces script weight, improves performance, and produces more reliable behavior across browser zoom levels and viewport changes. The piece on CSS Gap Decorations in Chrome 149 covered a parallel CSS-platform feature that landed in Chrome around the same time.

Why was anchor positioning not safe to ship on Safari before May 11?

Anchor positioning was not safe to ship on Safari before May 11, 2026 because three production-blocking bugs affected real patterns. The chains-of-three bug broke any pattern with three or more anchored elements in a positioning chain. The anchor() fallback unitless zero bug caused incorrect rendering when the fallback value was literal zero rather than a sized value. The display:contents anchor-scope bug broke positioning containment when the anchor element used display:contents.

For Webflow B2B SaaS pricing pages specifically, the chains-of-three bug was the consequential one. A pattern like "tooltip on a pricing card, sub-tooltip on the tooltip, sub-sub-tooltip on the sub-tooltip" did not render correctly on Safari, even though it worked perfectly on Chrome. The Phoenix Studio decision in late April was to defer the pattern rather than ship a JavaScript fallback, because the JavaScript path added complexity that Safari 26.5 would eventually resolve.

What did Safari 26.5 fix in anchor positioning?

Safari 26.5 fixed three anchor-positioning bugs on May 11, 2026. The first fix resolves chains of three or more anchor-positioned elements that did not resolve correctly in earlier Safari versions. The second fix corrects the anchor() fallback behavior when the fallback value was unitless zero. The third fix repairs the interaction between display:contents and anchor-scope, which previously broke positioning containment in nested structures.

For Phoenix Studio's deferred pricing-page pattern, the chains-of-three fix is the one that matters. The pattern now renders correctly on Safari 26.5 on iOS, iPadOS, visionOS, and macOS. The follow-up message to the client on May 11 confirmed the fix and proposed shipping the pattern in the next sprint. The piece on CSS path() and shape-outside() covered the broader CSS pattern surface that anchor positioning sits alongside.

Does anchor positioning work in Webflow Designer?

Anchor positioning works in Webflow Designer through the custom-code embed pattern. Webflow Designer does not yet expose anchor-name, position-anchor, or anchor() as native style options in the visual style editor, so the implementation requires writing the CSS in a Designer Embed block or in the page Head custom code. The pattern is well-documented and reliable; it is just not point-and-click in the current Designer build.

The Phoenix Studio implementation pattern is to define the anchor and positioned elements in the Designer visual canvas as normal Divs, then add a small CSS block via custom code that sets anchor-name on the anchor and position-anchor + anchor() values on the positioned element. The CSS block is usually 10 to 20 lines for a simple tooltip pattern. The Designer Interactions panel handles the show/hide behavior through standard hover or click triggers.

How do I build an anchor-positioned tooltip in Webflow?

To build an anchor-positioned tooltip in Webflow, create two Divs in the Designer: the anchor element (for example, a help icon next to a pricing-card feature) and the tooltip element (the floating tooltip body). Position the tooltip element absolutely. Add a Designer Embed block with CSS that sets anchor-name on the anchor element and uses position-anchor and anchor() values on the tooltip element to attach it to the anchor.

The Designer Interactions setup uses a standard hover trigger on the anchor element to toggle the tooltip's display state. The Phoenix Studio pattern adds a small entry animation (opacity and translate) using Designer Interactions on the same hover trigger. The full pattern is roughly 30 minutes of Designer work per tooltip site-wide, with the CSS block reusable across all tooltip instances. The pattern scales cleanly to dropdown menus and sticky CTAs with the same CSS architecture.

What's the difference between anchor() and @position-try?

The anchor() value function and the @position-try fallback chain serve different roles in CSS anchor positioning. The anchor() function returns a specific position value (such as the top, right, bottom, or left edge of the anchor) that the positioned element can use for layout calculations. The @position-try at-rule defines fallback positioning options that the browser uses when the primary positioning would overflow the viewport or collide with other elements.

For a Webflow B2B SaaS pricing-page tooltip, the typical pattern uses anchor() for the primary position (for example, "tooltip top-edge aligned to anchor bottom-edge") and @position-try to define a fallback position (for example, "tooltip bottom-edge aligned to anchor top-edge") when the tooltip would overflow the bottom of the viewport. The two together produce reliable tooltip placement that adapts to user scroll position and viewport size without JavaScript.

Should B2B SaaS pricing pages use anchor positioning now?

Yes, B2B SaaS pricing pages can use anchor positioning for tooltips, sticky CTAs, and dropdowns after May 11, 2026. The Safari 26.5 fixes bring Safari into closer parity with Chrome, which has supported the spec since Chrome 125 in May 2024. Firefox supports anchor positioning behind a flag and is on track for stable support in a future release. The cross-browser surface is now production-safe for the most common pricing-page patterns.

For Phoenix Studio's current retainer clients, the pattern recommendation is to use anchor positioning for new pricing-page tooltips and to migrate existing JavaScript-driven tooltip patterns when the next pricing-page redesign sprint runs. The migration is not urgent because the JavaScript patterns still work; it is durable cleanup work that reduces script weight and improves long-term maintainability. The piece on CSS color-mix() multi-color covered another CSS-platform feature that crossed the production-safe threshold around the same time.

How does anchor positioning interact with Webflow Interactions?

Anchor positioning interacts cleanly with Webflow Interactions because the positioning is handled by CSS and the show/hide behavior is handled by Interactions. The two systems do not conflict because they manage different properties (position vs. opacity/transform/display). The Phoenix Studio pattern is to use Designer Interactions for the trigger (hover, click, scroll-into-view) and CSS for the positioning, which separates concerns cleanly.

The one place to be careful is when Interactions use transform on the positioned element. Transforms can interfere with anchor positioning calculations in some edge cases. The workaround is to apply transforms to a wrapper element rather than the directly-anchored element, which keeps the anchor positioning math clean while preserving the Interactions animation behavior. The pattern is a Designer convention rather than a technical limitation.

What fallback should I write for older Safari versions?

For older Safari versions before 26.5, the fallback pattern is to detect anchor-positioning support with CSS @supports and provide a JavaScript-driven positioning fallback for unsupported browsers. The @supports query checks for position-anchor support, which is the most reliable feature-detection signal for anchor positioning. Browsers that fail the @supports check use the JavaScript fallback; browsers that pass use the CSS-native path.

For Phoenix Studio's deferred pricing-page pattern, the fallback approach is to ship the CSS-native pattern without a JavaScript fallback because the Safari users who would lack support (running Safari versions older than 26.5) are a small and shrinking percentage of the marketing-site visitor base. The decision is to accept slightly degraded behavior for the edge case rather than carry the JavaScript complexity indefinitely. The decision is client-specific and depends on the analytics breakdown for each B2B SaaS audience.

What anchor-positioning patterns are still risky in May 2026?

Anchor-positioning patterns that are still risky in May 2026 include patterns with very long anchor chains (five or more anchored elements), patterns that combine anchor positioning with view-transition animations, and patterns that use anchor positioning in nested scroll containers with scroll-driven animation. These edge cases are less reliable across browsers because the spec interactions are not fully tested.

For Webflow B2B SaaS marketing sites, the common patterns (tooltip-on-pricing-card, sticky-CTA-attached-to-feature-icon, dropdown-menu-attached-to-nav-link) are now reliable and production-safe. The edge cases that remain risky are not patterns that most B2B SaaS marketing sites need. The Phoenix Studio recommendation is to ship the common patterns confidently and to defer the edge cases until cross-browser interaction is tested more thoroughly, which is a normal pattern for CSS features as they mature.

If you run a B2B SaaS marketing site with pricing-page tooltips or sticky CTAs that you deferred earlier this year because of Safari support, drop me a line and tell me which pattern you are trying to ship. I will share the Phoenix Studio CSS snippet and Designer setup I am using on retainer client sites this week. Let's chat.