Interop 2027 Opens, and the 2026 Numbers Say the Web Is Converging

The Interop 2027 call for proposals opened on 3 September 2026, and the window closes on 23 September. The deadline is the least interesting number in the announcement. The scores for the year just finished are the ones worth reading twice: Chrome 98, Edge 98, Firefox 96, Safari 92.

Four engines, two positions

Those are the experimental Interop 2026 scores as of 3 September, quoted in the web.dev post that opened the next cycle. The same post puts them in context: "all browsers are in a much stronger position than at the same time last year".

Read them as two groups. Chrome and Edge are level at 98. Firefox sits two points back. Safari is six points behind the leaders and four behind Firefox. Six points is not a rounding difference on a shared test suite. It is a set of specific features that Safari does not pass, and those features are exactly where web code still carries a fallback, a polyfill or a browser check.

The height of the numbers matters as much as the spread. When two engines sit at 98, the remaining two points are a short list, and most of it is work in progress rather than missing intent. That is a different situation from a year where the leaders are in the eighties and the list of unimplemented features is long enough that nobody reads it. A high floor means a feature you adopt this year is more likely to work on the first try in more than one engine.

The gap is a map of your workarounds

If you maintain a stylesheet with a Safari-specific branch, the 92 tells you roughly how much of that branch is still load bearing. The useful exercise is to take the two or three features you still double-implement and check where each one sits. If a feature is inside the missing six points, the workaround stays until the number moves. If it is not, the workaround may be older than the bug it was written for.

A modern stylesheet usually has a handful of places where the code branches on an engine, and most of those branches carry a comment explaining why. Match the comments against the dashboard and the list divides into workarounds that are still needed and workarounds that have become folklore. The second group is where maintenance time quietly disappears, and it is also where regressions hide, because nobody remembers what the branch was protecting against.

What the dashboard number actually measures

Interop picks a set of focus areas for the year and tracks how many of the associated web-platform tests each engine passes. The dashboard figure is a pass rate over that selection, not a general score for browser quality. The selection is fixed for the cycle, which is what makes the four numbers comparable inside a year. Comparing one year with the next compares different test sets, so read the direction of travel and ignore small movement within a release.

What the figure does not cover is everything the year's selection left out. Performance differences, accessibility behaviour, the parts of a specification that pass tests but are awkward to use, and any feature a vendor objected to during selection all sit outside the number. A feature can be at 100 percent in every engine and still be a bad idea to adopt without a fallback, and a feature outside the selection can be broken everywhere. The score is a narrow, well-defined measurement, which is what makes it trustworthy and also what limits it.

The practical use of the number is comparison, not certification. Two engines at the same score have converged on the tested behaviour; that is a statement about tests passing, and it is the best public evidence available that a piece of CSS or JavaScript will behave the same way in both.

What gets accepted into 2027

The published selection process sets four conditions. A proposal needs a stable specification, no outstanding objection from a browser vendor, an implementation in at least one browser, and a test suite good enough to score against. Those conditions explain what Interop is for. It is a poor place to ask for a feature nobody has built, and a good place to ask for one that every engine has shipped except the one you support. Proposals go to the web-platform-tests repository, and the issue list is public.

Apple was reported to be preparing for it

Apple was separately reported in the week after the announcement to be preparing for Interop 2027 and asking developers for suggestions. That comes from a single outlet rather than from Apple, and the proposal window is the formal channel, so treat it as a signal about intent. The commitment that matters arrives with the score in twelve months.

What to do with this

• Check the Interop 2026 dashboard against the features you still work around, and write down which engine blocks each one.
• Watch the selected 2027 set when it is published. That list is the best available signal of which CSS and JavaScript features will become safe to use without a fallback.
• Do not delete a fallback because a score is high. Ship the fallback until the engine you support passes the tests.
• Diarise the window. It is annual, it is short, and missing it means waiting a year.

For most working developers the proposal window is not the actionable part. The selected set is. When it is published, it becomes the list of features you can expect to stop needing special handling, and reading it once is cheaper than discovering the change from a bug report after an engine updates. The score that follows tells you whether the expectation held.