CSS anchor positioning lands in Safari 26

For years, CSS authors have hacked together tooltips, popovers, and dropdowns with a mix of JavaScript, absolute positioning, and fragile geometry calculations. The promise of the CSS Anchor Positioning API is to make element‑to‑element layout a first‑class, declarative capability in CSS instead of a bespoke script in every codebase. With Safari 26, that promise is suddenly much closer to everyday reality.

In September 2025, Safari 26 landed native support for CSS Anchor Positioning across macOS and iOS, joining Chromium as the second major browser engine to implement the feature in stable releases. That single move dramatically shifts the compatibility story, bringing WebKit into near‑parity with Chrome’s implementation and giving front‑end developers a realistic path to shipping anchored UI patterns with far less JavaScript. At the same time, the spec is still evolving, implementations are slightly divergent, and Firefox lags behind, so this new power comes with a healthy dose of nuance.

What CSS Anchor Positioning Actually Solves

CSS Anchor Positioning is designed to answer a deceptively simple question: “How do I position one element relative to another?” Today you might reach for absolute positioning tied to the viewport, or rely on getBoundingClientRect() measurements in JavaScript to calculate where a tooltip, menu, or modal should appear. That approach works, but it tends to be brittle, hard to maintain, and easy to break when layouts become responsive or scroll containers get involved.

The anchor positioning API moves this responsibility into CSS. You declare one element as an anchor using anchor-name, and then you can position another element around it using position-anchor combined with properties like position-area and position-try. Rather than thinking in absolute pixels or viewport offsets, you describe relationships: “Place this popover above the button if there’s room, otherwise try below, then to the side.” The browser takes care of the geometry and adapts as layouts change.

That makes anchor positioning especially powerful for UI components that need to “stick” to a reference element: think dropdowns that follow their trigger as it scrolls, context menus that avoid clipping at container edges, and callouts that reposition themselves as content wraps. For design systems and component libraries, it promises less custom JS, fewer layout bugs, and more declarative control over complex positioning behavior.

Safari 26: A Milestone Release for WebKit

Safari 26, released on 15 September 2025, is the first WebKit-based browser version to ship CSS Anchor Positioning in stable form on desktop and iOS. That date marks a significant milestone because it brings WebKit into line with Chromium’s earlier implementation, meaning two of the three major engines can now handle anchor positioning natively. Compatibility tables updated in November 2025 even mark Safari 26.1 and 26.2 as “fully supported,” with Safari 26.0 and earlier still listed as “not supported,” underlining that the 26 series is the real watershed.

The WebKit team has highlighted anchor positioning as one of the flagship features in their Safari 26 tours. Articles recapping “New CSS Features in Safari 26” call it out as a standout addition, particularly for its impact on tooltips, modals, and pop‑ups. Commentary from WebKit engineers stresses how overdue the feature feels and how its arrival moves the web “one step closer to widely available support” for anchored UIs.

Because Safari remains a key browser across the Apple ecosystem, this release has immediate real‑world consequences. Previously, many teams avoided using anchor positioning in production because relying on just Chrome or Edge wasn’t enough. With Safari 26 in the mix, developers now see the implementation as a tipping point, especially when combined with polyfills or progressive enhancement strategies to bridge the remaining gaps.

Anchor Positioning Across the Apple Ecosystem

One of the quiet strengths of Safari 26’s implementation is its breadth. Anchor positioning isn’t limited to macOS desktop Safari; it is also available in iOS 26, iPadOS 26, and visionOS 26. That means any anchored UI you build can behave consistently across Apple’s primary platforms, from iPhones and iPads to Macs and Vision Pro devices.

This ecosystem-wide support matters because anchored patterns, tooltips, menus, popovers, floating panels, are especially common in touch interfaces and spatial environments. On mobile, anchoring is critical to ensure that popovers track their triggers correctly as users scroll or rotate the device. On visionOS, precisely positioned overlays and contextual UI panels benefit from a layout model that can reference anchors declaratively rather than relying on invasive JavaScript calculations.

For teams maintaining cross-platform design systems, Safari 26’s reach simplifies implementation: a single CSS-based positioning strategy can now cover a wide swath of Apple users. You still need to consider non‑Apple browsers and older versions, but the days when Safari and iOS blocked anchor positioning for a majority of mobile users are over. That improved coverage encourages more experimentation and early adoption, even before the feature reaches formal Baseline status.

Safari 26.1: Polishing the Experience

Safari 26.0 brought anchor positioning to users, but the WebKit team didn’t stop there. On 3 November 2025, Apple released Safari 26.1, explicitly calling out “a dozen improvements to CSS Anchor Positioning.” This rapid follow‑up release demonstrates how actively WebKit is iterating on the feature based on early feedback, spec discussions, and interoperability testing.

One key refinement in 26.1 involves position-try fallbacks. The browser now remembers the last successful fallback, which reduces layout jumps when conditions change. For example, if a tooltip originally fits above its anchor but later needs to move below because the viewport shrinks, Safari can recall the previously successful placement instead of cycling through all options on every change. That creates a more stable visual experience and minimizes distracting repositioning.

These sorts of quality improvements may sound subtle, but they are crucial for UI polish. Anchored menus that flicker between positions or popovers that visibly jump as content loads can feel broken, even if the underlying layout logic is sound. By smoothing out these behaviors, Safari 26.1 and 26.2 help anchor positioning feel less like an experimental API and more like a reliable tool suitable for production interfaces.

Living Spec, Evolving Syntax

Even as Safari 26 ships anchor positioning, the underlying standard is still a work in progress. The CSS Anchor Positioning Level 1 spec remains a W3C Working Draft, with updates logged on 26 March 2024, 4 October 2024, 9 May 2025, and 7 October 2025. Safari’s implementation landed while this document continues to evolve, meaning developers are effectively working with a living standard rather than a fully frozen Level 1 recommendation.

Chrome’s implementation history illustrates how fluid the syntax has been. During development, properties like inset-area were renamed to position-area, and position-try-options became position-try-fallbacks, among other changes. Modern documentation, demos, and tutorials, including those aiming for Safari parity, now reflect the later naming, and Safari 26’s guidance follows suit: use anchor-name on the reference, and position-anchor plus position-area and position-try-* on the positioned element.

For developers, the upshot is that older tutorials or prototypes may use outdated syntax that no longer works in modern Safari or Chromium. When adopting anchor positioning, it’s essential to consult up‑to‑date docs and confirm the property names and values against current browser behavior. You should also expect incremental adjustments in future browser versions as the spec is refined, though the presence of two major shipping implementations makes large breaking changes less likely.

Safari vs. Chrome: Interoperability and Edge Cases

With both Safari and Chromium implementing anchor positioning, interoperability is in much better shape than when Chrome was alone. However, real‑world testing is already uncovering differences in behavior that matter for polished UI. OddBird’s October 2025 article, based on their polyfill work and testing, documents one such divergence around how anchored elements interact with their containing block.

In Safari 26, when an anchor‑positioned element approaches the boundaries of its containing block, the browser may shift the positioned element fully into the available area, even if that means partially covering the anchor itself. Chrome, by contrast, clamps differently: it keeps the anchor fully visible, and instead clips the positioned element when it conflicts with the container’s edges. Both approaches are defensible, but they lead to noticeably different results for tooltips and popovers near container boundaries.

These differences are exactly the kind of issues standards discussions are meant to resolve. As the spec evolves and browsers iterate, the goal is to converge on consistent behavior so authors can rely on predictable results. For now, you should test anchored components in both Safari and Chromium, particularly in edge cases like scrollable containers, nested anchors, and elements near viewport or container edges. Progressive enhancement and careful fallback styles can help mitigate inconsistencies while the implementations mature.

Polyfills and the Role of Firefox

Despite Safari 26’s release, CSS Anchor Positioning remains “Limited availability” in late 2025 according to the Web Platform Features Explorer. Safari 26+ and Chrome/Edge 125+ ship native support, but Firefox has no stable implementation yet, though Nightly builds and positive signals from Mozilla indicate eventual adoption. This gap is what currently blocks anchor positioning from entering the “Baseline” interoperable set of features.

In this landscape, polyfills continue to play an important role. OddBird’s CSS Anchor Positioning polyfill, originally conceived to patch the absence of native support across all browsers, released v0.7.0 in October 2025 with improved behavior around Shadow DOM at almost the same moment Safari 26’s native implementation landed. As a result, the polyfill’s focus is shifting: instead of covering all browsers, it is increasingly aimed at Firefox and older engines that lack native support.

For teams that want to adopt anchor positioning today, a common strategy is to rely on native CSS where available and fall back to the polyfill or a different layout approach elsewhere. Because both Safari and Chromium now share a broadly aligned syntax, the same CSS declarations can power native behavior in those browsers while a polyfill handles the rest. Over time, as Firefox stabilizes its implementation, the need for such polyfills should diminish, but for now they are a key part of a cross‑browser deployment plan.

Practical Usage Guidance for Safari 26 Developers

To use anchor positioning effectively in Safari 26, the recommended pattern is to mirror the modern Chromium syntax so that one codebase works across both engines. On the reference element (for example, a button that triggers a tooltip), you define an anchor name using anchor-name: --my-anchor;. On the positioned element (the tooltip, popover, or menu), you specify position-anchor: --my-anchor; and then use position-area to describe where it should appear relative to the anchor, combined with position-try or position-try-fallbacks to express alternative placements.

This approach allows you to define a priority list of placements, top, bottom, left, right, or more specific areas, and let the browser decide which one fits best in the current layout. Because Safari 26 and Chrome 129+ follow the same general syntax, you can share demos, code samples, and component implementations between them without browser‑specific branches or large chunks of imperative geometry code.

Accessibility remains a critical consideration. While CSS controls visual positioning, it does not establish semantic relationships between elements. Guides from browser teams emphasize that developers must still use ARIA attributes, such as linking an anchored popover with aria-details or aria-describedby, to convey relationships to assistive technologies. Keyboard focus management and proper labeling remain the developer’s responsibility, even as the layout itself becomes more declarative.

With Safari 26 and 26.1, CSS Anchor Positioning crosses an important threshold from experimental curiosity to practical tool. WebKit’s implementation, spanning macOS, iOS, iPadOS, and visionOS, closes a longstanding gap in the platform and gives front‑end developers the confidence to start relying on anchor‑based layouts in real products. Combined with Chromium’s earlier support and active polyfill work, the ecosystem now offers a credible path to shipping anchored UI patterns that are lighter on JavaScript and more resilient in the face of responsive design.

There are still caveats: the spec is a living draft, Firefox has yet to ship stable support, and subtle behavioral differences between engines require careful testing. Yet developer sentiment is clear, anchor positioning is already viewed as a game‑changer and a favorite new feature in community surveys. If you design tooltips, menus, dialogs, or any UI that needs to follow another element, Safari 26’s arrival is the sign to start exploring the CSS Anchor Positioning API, implementing it progressively, and helping shape its future through real‑world feedback.