Tools · Sep 14, 2026 · 6 min read

Interop 2026: what the browser makers agreed to fix this year

Twenty focus areas and four investigations, chosen by the people who ship the engines. What Interop tells you that Baseline can't, and how to read the dashboard.

Interop 2026 is a list of web platform features that the organisations behind the browser engines have collectively agreed to make work the same way across browsers this year, measured by automated tests that run continuously on the Interop 2026 dashboard.

It answers a different question from Baseline. Baseline tells you what has already shipped everywhere; Interop tells you where the remaining cross-browser differences are being fixed. One is a shipping decision, the other is a planning signal.

github.com ↗Interop 2026 focus areas and investigation effortsThe full list with proposal issues, specs and test queries. Source: the Interop Project

The twenty focus areas

Focus area	What it covers
Container style queries	`@container style()` conditions on custom properties
CSS anchor positioning	Positioning one element relative to another — tooltips, menus
CSS `attr()`	Typed attribute values, as in `attr(data-background type(<color>), red)`
CSS `contrast-color()`	Automatic black-or-white text colour
CSS `zoom`	The property that scales an element and affects layout
Custom highlights	Styling arbitrary text ranges without extra DOM
Dialogs and popovers	`<dialog closedby>`, the `:open` pseudo-class, `popover="hint"`
Fetch uploads and ranges	`ReadableStream` request bodies, `FormData`, the `Range` header
IndexedDB	The `getAllRecords()` methods on stores and indexes
JSPI for Wasm	JavaScript Promise Integration for WebAssembly
Media pseudo-classes	`:playing`, `:paused`, `:buffering` and four others
Navigation API	Plus the `precommitHandler` option to `intercept()`
Scoped custom element registries	More than one registry, so tag names can coexist
Scroll-driven animations	`animation-timeline`, `scroll-timeline`, `view-timeline`
Scroll snap	Panning and snapping inside scroll containers
CSS `shape()`	Path-like shapes for `clip-path` and `shape-outside`
View transitions	Same-document and cross-document, plus `blocking="render"`, `rel="expect"` and `:active-view-transition-type()`
Web compat	ESM module loading, scroll-vs-animation event timing, unprefixing `-webkit-user-select`
WebRTC	Continued interoperability, including 2025's remaining failures
WebTransport	Client–server data over HTTP/3

Four investigation efforts sit alongside them, for work that isn't yet testable enough to score: accessibility testing, JPEG XL, mobile testing and WebVTT. An investigation aims to bring a feature up to the bar where it could become a focus area later — so a feature appearing here is a signal that reliable cross-browser behaviour is still some way off.

What Interop tells you that Baseline doesn't

Question	Ask	Because
Can I use this without a fallback?	Baseline	It reports support that has already shipped in every core browser
Will the edge cases stop biting this year?	Interop	The engines have committed to the tests, and progress is public
Is the browser difference I hit a known one?	Interop, then the proposal issue	Each focus area links the proposal and its test query
Should I expect this feature at all?	Neither	Interop only covers features already in a mature standard

That last row is the limit worth internalising. The project's own scope document requires that everything selected "must be defined in a sufficiently mature standards-track web specification" and must be testable with automated tests in web-platform-tests or Test262. Interop is not a roadmap for new features, and a feature's absence from the list says nothing about whether it's coming.

Reading the dashboard without fooling yourself

The dashboard shows, per focus area, the percentage of the selected tests that each engine passes, plus an overall score counting tests that pass in every browser. Three things follow.

A score is about tests, not about a feature being finished. The tests are the ones chosen for that focus area. A high score means those pass; it does not mean nothing else in the feature is broken.

The overall number is the intersection. Because it counts tests passing everywhere, one engine's gap holds the total down. That's the point — interoperability is the shared subset — but it means the headline figure is not an average of engine quality.

Scores move. They are recomputed as tests and browsers change, which is why there are no numbers in this article. Open the dashboard when you need a figure, and treat any score quoted in an article, this one included, as a snapshot of the day it was written.

The carry-overs are the interesting part

Several 2026 areas are explicitly continuations of 2025 work: CSS anchor positioning, CSS zoom, view transitions, the Navigation API and WebRTC are all carried over, and the accessibility, mobile-testing and WebVTT investigations are continuations too.

Read that as a difficulty signal. A feature that needed a second year of coordinated effort is a feature where browser behaviour diverged enough that a single year of fixes wasn't sufficient. If you're planning work on anchor positioning or the Navigation API, budget for engine-specific behaviour and keep a fallback, even where support tables look green.

The reverse signal is just as useful: several areas on the 2026 list are features that already have support everywhere and are being polished. Media pseudo-classes and container style queries are both Baseline newly available — their presence here is about the last few percent of behavioural differences, not about whether you can use them.

What to do with this list

Cross-reference it against your own backlog. If a feature you're about to adopt is a focus area, read its proposal issue. It usually names the specific behaviours that differ, which is exactly what you'd otherwise discover in QA.
Use it to time fallback removal. A focus area finishing its year is a reasonable trigger to revisit workarounds you added for engine-specific bugs — after re-testing, not instead of it.
Propose something for 2027. Proposals for Interop 2027 are open at the time of writing, through the Interop repository's issue templates. The guidance asks for evidence: browser bug reports, Stack Overflow complaints, survey data, or documented workarounds in real libraries. A well-evidenced proposal from someone who hit the bug in production carries more weight than a feature request.

That third point is the one most designers and front-end developers skip. The focus areas are community-proposed; the reason your least favourite inconsistency isn't on the list may be that nobody filed it with evidence.

FAQ

Is Interop 2026 a list of new features?

No. Everything on it is already specified and, in most cases, already implemented somewhere. The work is on making implementations agree.

Does a feature reaching 100% mean it's bug-free?

No. It means the tests selected for that focus area pass in that browser. Feature areas are much larger than their Interop test selections.

Who decides what goes on the list?

The Interop team — representatives from organisations that contribute substantially to browser engines, currently including Apple, Bocoup, Google, Igalia, Microsoft and Mozilla — selects from proposals submitted by the web community.

Where does Baseline fit?

Baseline answers "has this shipped everywhere?" and Interop answers "are the differences being fixed?". Use Baseline to decide whether to ship a feature, and Interop to decide how much to trust it at the edges.

Sources

Interop 2026 README — the focus areas, investigation efforts and their resources
The Interop Project README — scope, requirements for focus-area proposals, and the 2027 proposal round
Interop 2026 dashboard — live scores per focus area
web-platform-tests — the test suite the scores are computed from