The Polyfills and Libraries You Can Finally Delete in 2026

Last week smoothscroll-polyfill was downloaded 1,125,110 times from npm. dialog-polyfill, 253,743 times. container-query-polyfill, 74,300 times. moment, 36,910,362 times.

Every one of those solves a problem the browser solved years ago. scroll-behavior has been Baseline Widely available since September 2024. <dialog> since September 2024. Container queries since August 2025. People are still installing the workarounds, because nobody ever tells you when it is safe to stop.

So I went and checked. Not by reading release announcements, which are written by the people who shipped the thing and are optimistic by design, but by querying api.webstatus.dev directly for every feature on the list. Some of the results surprised me, and two of them contradict blog posts I had bookmarked as reliable.

Here is what the data actually says about baseline 2026 css features, and where the announcements are ahead of reality.

Want the printable version? Download the complete reference as a PDF — 9 pages, 24 features with verified Baseline dates, no login required.

Newly Available and Widely Available Are Not the Same Word

This is the single most expensive misunderstanding in front-end right now, and it costs people production bugs.

Baseline has three states. Limited availability means at least one of the four core browser engines does not support it. Newly available means all four do, in their current stable versions, on desktop and mobile: Chrome, Edge, Firefox, Safari. Widely available means 30 months have passed since the newly available date.

That 30-month gap is the whole ballgame. It is not a formality. It exists because the day Safari ships a feature is not the day Safari users have it. People do not update. Devices stop getting updates. Corporate fleets freeze versions. The 30 months is the industry's rough estimate for how long it takes a feature to reach roughly 95% of users globally.

So when someone writes "X is now Baseline," ask which kind. A feature that went Newly available in March 2026 is safe for a developer tooling dashboard and genuinely risky for a checkout flow on a site whose audience includes a lot of two-year-old Android phones. Same feature, same date, opposite decisions.

I have watched developers ship a Newly available feature to a client site, get a bug report from someone on an older iPhone, and then spend a day being confused about it, because the badge on the documentation page said green.

Interop 2026 Has 20 Focus Areas, Not 26

I want to flag this because I was told 26 and repeated it before checking, which is exactly the habit this post is arguing against.

The Interop 2026 README in the web-platform-tests repo lists 20 focus areas: container style queries, CSS anchor positioning, CSS attr(), contrast-color(), CSS zoom, custom highlights, dialogs and popovers, fetch uploads and ranges, IndexedDB, JSPI for Wasm, media pseudo-classes, the Navigation API, scoped custom element registries, scroll-driven animations, scroll snap, shape(), view transitions, web compat, WebRTC, and WebTransport. Plus four investigation efforts: accessibility testing, JPEG XL, mobile testing, and WebVTT. Fifteen are new, five carry over from 2025.

Interop is the other half of the picture when you are working out which baseline 2026 css features are real. For ordinary client work, most of that list is irrelevant. You are not shipping JSPI for Wasm on a dentist's website. The ones that will touch normal projects are dialogs and popovers, view transitions, scroll-driven animations, scroll snap, and attr().

And here is the useful thing about Interop that people miss: a feature being an Interop focus area is a signal that it is not reliable yet. That is the point of the exercise. The browsers picked it because the pass rates are uneven. Scroll-driven animations being on the 2026 list is a warning, not an endorsement.

The Ones You Can Delete Today Without Thinking

These are the baseline 2026 css features with no asterisk attached. All Baseline Widely available, verified against api.webstatus.dev rather than a blog post, with their widely-available dates.

Container queries. Newly available 14 February 2023, Widely available 14 August 2025. Replaces container-query-polyfill and most of the JavaScript resize-observer plumbing people wrote to fake it. Delete it.

:has(). Newly available 19 December 2023, Widely available 19 June 2026. Replaces css-has-pseudo, which is still pulling 7.7 million weekly downloads, mostly as a passenger inside postcss-preset-env. If you are on a recent preset-env config, check whether it is still transpiling :has() into class-toggling JavaScript that you no longer need.

Cascade layers. Widely available 14 September 2024. Replaces the specificity-wrangling conventions you invented, and a decent chunk of what CSS Modules and BEM were compensating for.

Subgrid. Newly available 15 September 2023, Widely available 15 March 2026. This one only just crossed. Replaces the nested-grid hacks and the display: contents tricks.

<dialog>. Widely available 14 September 2024. Replaces dialog-polyfill and, for most simple cases, your modal library. A quarter of a million people a week are still installing the polyfill.

color-mix(). Widely available 9 November 2025. Replaces the Sass colour functions you were keeping a build step alive for.

CSS nesting. Newly available 11 December 2023, Widely available 11 June 2026. Replaces the main reason a lot of small projects still have a preprocessor in the pipeline at all.

scroll-behavior: smooth. Widely available 14 September 2024. Replaces smoothscroll-polyfill, which as of last week still had over a million weekly downloads.

Scroll snap. Widely available since 15 July 2022. That is four years ago. If you have a carousel library in a project and its only job is horizontal snapping, it is dead weight. I went through this exercise in Every JavaScript Animation Library You Can Replace With 3 Lines of CSS, and scroll snap was the single biggest win.

Array.prototype.at(), structuredClone(), and friends. Widely available 14 September 2024. core-js did 71 million downloads last week. Most projects that ship it do so because a build config from 2019 targets browsers nobody uses anymore. That is not a polyfill decision, it is a browserslist decision, and I will come back to it.

The Ones That Are Newly Available and Nothing More

These work in all four engines. They have not aged 30 months. Read that as "ship it if you understand your audience, not because a badge told you to."

View transitions. Newly available 14 October 2025, when Firefox 144 shipped it. Chrome had it in March 2023 and Safari in September 2024, so the gap was entirely Firefox. Two and a half years of blog posts said "view transitions are here" while a whole engine did not have them. It is genuinely good, it degrades gracefully to a normal instant swap, and that graceful degradation is why I am comfortable using it now.

The Popover API. Newly available 27 January 2025, gated by Safari iOS 18.3. Replaces the show-hide logic in your tooltip and dropdown code, along with the light-dismiss handling everybody gets wrong. It does not degrade gracefully: on an unsupported browser the popover content is just visible on the page, which looks broken. Test that before you ship it.

text-wrap: balance. Newly available 13 May 2024. Replaces balance-text and the JavaScript headline-balancing scripts. This one is a pure progressive enhancement, so it is a genuinely free win.

light-dark(). Newly available 13 May 2024. Replaces a pile of duplicated custom properties in your dark mode setup.

Relative colour syntax. Newly available 16 September 2024. Replaces more Sass colour maths.

@scope. Newly available 24 March 2026, when Safari 26.4 landed it. Six months old at the time of writing. I like it a lot and I am not putting it in a client project's critical path yet.

field-sizing. Newly available 16 June 2026, when Firefox 152 shipped. Replaces the auto-growing textarea script. Three months old. Progressive enhancement, so low risk, but let us be honest that "Baseline" and "three months old" are sitting in the same sentence here.

contrast-color(). Newly available 10 April 2026.

Trusted Types. Newly available 24 February 2026. Worth a post of its own, because the interesting part is not the Baseline date, it is what Trusted Types does to your CSP and your third-party scripts once you turn it on.

The Ones Where the Announcement Was Wrong

This is the section I actually wrote this post for.

Scroll-driven animations are still Limited availability. Not Newly available. Limited. Chrome shipped them in July 2023, Safari 26 in September 2025, and Firefox has not shipped them at all. api.webstatus.dev returns no Firefox entry for the feature. It is an Interop 2026 focus area precisely because it is not done. If you have seen a "scroll-driven animations are Baseline now" post, it was wrong, or it was describing Chrome.

text-wrap: pretty is Limited availability. Chrome 117 in September 2023, Safari 26 in September 2025, no Firefox. Its sibling text-wrap: balance reached Newly available in May 2024 and pretty did not, which is a fun trap: the two get written about together constantly.

The Temporal API is Limited availability. Firefox 139 in May 2025, Chrome 144 in January 2026, and no Safari. So the answer to "can I finally delete moment" is: yes, but not by using Temporal natively. You still need temporal-polyfill (3.5 million weekly downloads) or you use Intl.DateTimeFormat and native Date for the 80% of cases that are just formatting.

accent-color is Limited availability, which I did not believe until I read the browser table. Chrome desktop 93, Firefox 92, Edge 93, Safari 26.2 in December 2025, and no entry for Chrome on Android. One missing row in one browser on one platform, and the whole feature sits below the line. Worth knowing before you rely on it for a form's visual identity.

CSS anchor positioning is contested. api.webstatus.dev reports the composite feature as Limited, some coverage in early 2026 called it Newly available, and there is an open argument in the web-features repo about how the feature should be split. I dug into that whole mess separately in CSS Anchor Positioning Shipped Everywhere. Here's What You Can Delete., so I will not repeat it here beyond saying: the disagreement is real, and it is about how the feature is defined, not about who is lying.

The pattern in all five cases is the same. Somebody shipped it in Chrome, wrote about it well, and the ecosystem quietly rounded "available" up to "safe." That is the same failure mode as most of the website best practices that stopped working years before anyone updated the advice.

How to Decide, Instead of Guessing

Two things, and neither takes long.

Put Baseline in your browserslist. Browserslist supports Baseline queries directly now. "baseline widely available" in your package.json targets the browser versions that have every Widely available feature. "baseline newly available" is the aggressive setting. "baseline 2025" targets everything that reached Newly available by the end of 2025. This is the fix for the core-js problem: most projects are shipping legacy JavaScript to modern browsers because of a browserslist config nobody has touched in four years, not because they need to.

Then look at your own analytics, not a global chart. Baseline's 30-month rule is calibrated to "roughly 95% of users globally." Your users are not global. A B2B SaaS with a US enterprise audience has a completely different Safari-version distribution than a consumer site with heavy traffic from older Android devices.

Open your analytics, go to browser and OS version, and set the window to the last 30 days. You are looking for one number: what percentage of your sessions are on a browser version older than the one that shipped the feature. If it is under 0.5% and the feature degrades gracefully, ship it. If it is 4% and the feature breaks the layout when it is missing, do not. That is the entire decision, and it takes about three minutes per feature.

That analytics check is also how I decide whether something is worth deleting at all, the same way I approach a general cleanup pass in 10 Things You Can Delete From Your Website Today.

What I Actually Do

I have a rule that has served me well for client work: Widely available means ship it, Newly available means ship it only if it degrades gracefully, Limited means keep the library.

text-wrap: balance degrades to normal wrapping. Ship it. field-sizing degrades to a fixed-height textarea. Ship it. The Popover API degrades to content that is visible when it should be hidden. That one gets a check. Scroll-driven animations do not exist in Firefox. Keep the library.

The uncomfortable part is that this rule does not tell you what to do about @scope, which is six months old, which I want to use, and which I keep not using on client projects while using it happily on my own. I do not have a clean answer for that. It is a judgement call dressed up as a rule, and I would rather admit it than pretend the dates make the decision for me.

What I am confident about is the direction of the error. Almost nobody is being too cautious. The bundles I open are full of workarounds for problems that were fixed while the project was in maintenance mode, and the fix is the same every time: check the API, not the announcement, then check your own traffic. A lot of the CSS-versus-tooling arguments I have had with designers come down to this too, which is roughly what 10 Figma Plugins You Don't Need If You Just Learn These CSS Tricks was about.

If you want someone to run that pass over a real project and tell you exactly what comes out, that is a good chunk of what I do at Wunderlandmedia.