You can finally delete your popover library

CSS anchor positioning, the Popover API, and View Transitions all sit at Baseline in 2026, so most teams no longer need a dependency for dropdowns, tooltips, and page transitions.

Somewhere in your package.json there’s a dependency whose only job is to keep a tooltip attached to the button that opened it. Maybe it’s Floating UI, maybe it’s Popper.js, maybe it’s a homemade getBoundingClientRect calculation that someone wrote three jobs ago and nobody wants to touch. For years that was just the cost of doing business: browsers didn’t know how to tether one element to another, so you shipped code that did.

That excuse quietly expired in 2026. CSS anchor positioning, the Popover API, and the View Transitions API have all crossed into Baseline, the cross-browser support label maintained by the WebDX Community Group and surfaced on MDN and web.dev. Put together, they cover the exact three jobs a huge slice of UI libraries exist to do: position a floating element relative to its trigger, manage its focus and dismissal, and animate the transition between states. None of it needs a script tag anymore.

What “Baseline” is actually promising you

Baseline has two stages, and the difference matters more than the headline. “Newly available” means a feature works in the current stable release of all four core engines — Chrome, Edge, Firefox, and Safari, on desktop and mobile. “Widely available” means 30 months have passed since that point, which is the threshold where even slow-moving enterprise fleets and school-issued laptops have caught up.

Anchor positioning, Popover, and View Transitions are all Newly available, not Widely available yet. That’s not a reason to ignore them — it’s a reason to be specific about your audience. A marketing site aimed at people who update their phones can ship these features today. A banking portal with a large population of frozen enterprise Chrome installs should check its own analytics before leaning on them as load-bearing UI, per the Interop 2026 rundown published by DualMedia on August 26, 2026.

Anchor positioning: no more resize listeners

This is the one most likely to let you delete a dependency outright. CSS anchor positioning lets you name an anchor and tether another element to it, in pure CSS, without JavaScript recalculating a rectangle on every scroll and resize event:

.menu-button {
  anchor-name: --menu;
}

.dropdown {
  position: absolute;
  position-anchor: --menu;
  position-area: bottom center;
  margin-top: 8px;
}

Firefox 147 shipped support back in January 2026, which is what tipped the core properties — anchor-name, position-anchor, position-area — into Baseline Newly available. That’s the entire job Floating UI and Popper.js were built to do, handed to the rendering engine instead of a bundle.

There’s one caveat worth keeping in your notes: @position-try, the part of the spec that flips a popover to the other side of its anchor when it would otherwise overflow the viewport, needs Safari 18.4 or newer. Apple has kept shipping refinements since — Safari 26.4 (March 24, 2026) fixed alignment overflow in scrollable containing blocks and a style-resolution loop bug, Safari 26.5 (May 11, 2026) addressed anchor chains and fixed-position elements anchored to sticky boxes, and Safari 26.6 (July 27, 2026) continued the cleanup. Translation: the core feature is safe, but if your dropdown needs smart flipping near screen edges, keep a sane default position-area as a fallback rather than assuming @position-try everywhere.

The popover attribute promotes any element to the browser’s top layer with focus handling, light-dismiss on outside click, and Escape-to-close already built. That’s a genuinely fiddly pile of accessibility work most teams either skip or import:

<button popovertarget="info">Details</button>
<div id="info" popover>Rendered in the top layer, dismisses on outside click.</div>

Popover reached Baseline Newly available back in January 2025, which by the DualMedia team’s read makes it a reasonable default with a fallback for older browsers rather than a wait-and-see feature — the 30-month mark for it hits Widely available around July 2027, but the realistic risk today is low for anything but the most conservative enterprise audience. Pair it with anchor positioning and you get framework-grade menus, teaching tips, and dropdown controls with zero UI library involvement.

View Transitions: crossfades without the FLIP dance

Smooth animated transitions between two UI states used to mean either a framework’s built-in transition system or hand-rolled FLIP calculations: clone the nodes, measure their positions, animate manually, clean up. The View Transitions API collapses that into one call:

document.startViewTransition(() => {
  renderNewList() // the browser animates the change
})

::view-transition-old(card) {
  animation: fade-out 0.25s;
}
::view-transition-new(card) {
  animation: fade-in 0.25s;
}

Same-document View Transitions became Baseline Newly available in 2025, after Firefox 144 shipped support that October. Chrome has kept extending the surface since — new pseudo-classes :active-view-transition and :active-view-transition-type() reached Baseline in April 2026, letting you style specific rules while a transition is actively in flight. Per the Can I Use data cited in the DualMedia piece, current support spans Chrome/Edge 150, Safari and iOS Safari 18+, Firefox 152, and Samsung Internet 23+ — everything except Opera Mini and KaiOS Browser, which is a reasonable trade for most consumer-facing sites.

Cross-document (multi-page) View Transitions are a different story: Firefox hasn’t shipped them yet, so if you’re navigating between full page loads rather than mutating a single-page app’s DOM, treat that piece as progressive enhancement behind a feature check, not something the whole experience depends on.

Where this sits inside Interop 2026

None of this happened by accident. Interop 2026 is the sixth edition of the joint effort between Apple, Google, Igalia, Microsoft, and Mozilla to make the same code behave the same way across engines. Mozilla has said more than 150 proposals were submitted for this year’s program, with 20 focus areas selected from 33 proposals plus four investigation areas, announced on February 12, 2026. Dialogs and popovers, View Transitions, scroll-driven animations, scroll snap, and scoped custom element registries are all explicitly on this year’s list — meaning the gaps that remain in each of these features (Firefox’s missing cross-document transitions, Safari’s still-maturing anchor positioning edge cases) are actively being worked, not stalled.

That’s a useful signal for prioritization. Features on the current Interop list tend to close their remaining browser gaps faster than features that aren’t, simply because there’s a standing cross-vendor test suite tracking them.

What to actually check this week

The concrete, testable step here isn’t “adopt Baseline,” it’s an audit. Pull up your package.json and look for Floating UI, Popper.js, Tippy.js, or a homemade positioning utility, and ask whether the component it powers is actually a simple anchored dropdown, tooltip, or menu — the case anchor positioning plus Popover now covers natively. If your team already leans toward a lean front-end stack with as little shipped JavaScript as the job requires, this is the kind of change that fits that bias directly: fewer kilobytes, fewer resize-listener edge cases, one less package to patch during the next security advisory.

Three habits make this an ongoing practice instead of a one-time cleanup. Check the Baseline badge on a feature’s MDN page before reaching for a library — it states the exact status and the year it crossed over. Point your bundler and linter at a Baseline-aware browserslist target so a non-Baseline feature gets flagged before it reaches code review instead of after a bug report. And if your own team is weighing how much of this kind of front-end debt is worth clearing versus leaving alone, that’s exactly the kind of prioritization conversation we help clients work through under performance and technical audits.

What still needs a fallback

Not everything in this space is safe to ship naked yet, and treating a demo-worthy feature as production-ready is how you generate the bug report from the one person still on an old Safari. Customizable <select> styling via appearance: base-select is Chromium-only as of mid-2026, with Firefox and Safari still behind flags. text-box-trim for tightening the space above and below text is still unsupported in Firefox. Scroll-driven animations (animation-timeline, scroll(), view()) work in Chromium and Safari but not Firefox — they degrade gracefully if you treat them as enhancement, so that’s a safe pattern, not a blocker. And scoped custom element registries only shipped first in Safari 26.0, which is impressive but not the same thing as interoperable.

The pattern repeats: one engine trails the other two by roughly six to twelve months on almost everything in this list. Check the badge, then decide whether to ship it as core UI or as an enhancement with a fallback — the three features covered above have already cleared that bar; the rest mostly haven’t yet.

The takeaway

Anchor positioning, Popover, and View Transitions replacing a chunk of your dependency tree isn’t a hypothetical for next year — it’s already Baseline, already shipping in stable browsers, and already being actively hardened through Interop 2026’s cross-vendor test suite. The honest audit is short: open your lockfile, find the positioning library, and ask whether the component it’s propping up is actually simple enough that the platform now does the job for free. For a lot of dropdowns and tooltips, the answer is yes.