Every team has a list. The CSS property that works in three browsers and silently does nothing in the fourth. The form control that needs a polyfill on iOS and nowhere else. The layout hack with a comment above it that says // Safari.
Most of that list never goes anywhere. You work around it, ship, and forget which workaround was for which browser until someone new asks.
Interop 2027 opened for proposals on September 3 and closes on September 23, 2026. It is the one window each year where a working developer can put a specific interoperability failure in front of Apple, Google, Microsoft and Mozilla at the same time, and have all four commit to fixing it against a public scoreboard.
Two days left. Here is how to spend them well.
What Interop actually commits browsers to
Interop is not a wishlist or a standards venue. It takes web technology that has already been specified and shipped somewhere, and drives every engine to the same behaviour — measured continuously by Web Platform Tests on a public dashboard.
That framing decides everything about what gets accepted. As the WebKit team put it in their call for ideas, there are two essential criteria: testability and a mature web standard. If the thing you want does not exist yet, Interop is the wrong door — that conversation belongs in the CSS Working Group issue tracker or TC39. If it exists but nobody has written tests for it, it can still be proposed, but as an Investigation rather than a Focus Area. Investigations are assignments the Interop group gives itself to improve testing infrastructure; Focus Areas are the scored items on the dashboard.
The track record is the argument for bothering. CSS layout and utilities, View Transitions, anchor positioning, popover and shadow DOM all moved from "mostly works, depends" to "just use it" through focused Interop attention. Those are features your team now reaches for without checking a support table first. Each of them started as someone's complaint.
The current scoreboard, for context
As of September 3, the Interop 2026 experimental scores stood at Chrome 98, Edge 98, Firefox 96 and Safari 92 — every engine further along than at the same point the previous year. That matters when you are writing a proposal, because it tells you the project is not short of capacity. It is short of well-argued submissions.
What separates a proposal that lands from one that does not
WebKit published a rubric that is worth treating as a literal checklist. A strong proposal is:
Specific. One feature, or a narrow group of genuinely related features. Their example is exact: propose font-size-adjust, not "typography". A proposal that asks for a whole subsystem gives the selection committee nothing to score and no way to say yes to part of it.
Impactful. Describe the interoperability problem, not the feature. "Safari's implementation of X diverges from the spec in case Y, which forces every site doing Z to branch" is a proposal. "X is great and should work everywhere" is not.
Valuable. Explain who benefits and why this beats the existing workaround. Use cases from your own production code carry real weight here — the committee reads a lot of abstractions and very few concrete ones.
Stable. Link the specification. The fastest way to find it is the Specifications section at the bottom of the relevant MDN page.
Tested. Link current WPT coverage. If coverage is thin, say so and explain how tests could be written this autumn. A proposal that arrives with a credible testing plan is substantially stronger than one that assumes someone else will handle it.
The underlying instruction is to make the case in the proposal itself. Do not assume the reader has followed the last three years of discussion about your feature, or knows how many sites depend on it. If there are hundreds of candidates, your job is to explain why this one stands out — and to provide evidence that other developers share the view.
Finding evidence in the next two days
Three tools do most of the work.
webstatus.dev is the fastest way to confirm a feature meets the bar before you spend an hour writing. It shows implementation status per engine and Baseline state, so you can immediately tell whether you are looking at a genuine interop gap (shipped in some engines, inconsistent) or something that simply is not implemented yet.
The developer-signals repository is the one most people miss. It is a public record of what developers have asked for, sorted by reactions, often with published use cases already attached. Many Interop 2026 Focus Areas came from its top 20, or from survey data like State of CSS. If your feature is in there, cite the issue and its reaction count — that is exactly the "evidence a lot of people share your belief" the rubric asks for.
wpt.fyi gives you the test numbers. Filter to the aligned experimental view, find your feature's directory, and screenshot or link the per-engine pass rates. A proposal containing "Safari passes 61% of these 340 tests" is a different document from one containing "Safari has bugs here".
Check for duplicates before you write
Before filing anything, read the open focus-area proposals. If someone has already proposed your feature, adding a comment with your production use case is more useful than opening a second issue — duplicates split the signal and make both look weaker. WebKit is explicit on this point: supporting an existing issue beats creating a near-identical one.
When you are ready, submit through the Focus Area proposal template. Everything filed before September 23 goes through the published selection process.
If you have no time to write one
Reading the open proposals and reacting to the ones that match your team's pain takes ten minutes and is not a wasted gesture. Reaction counts and substantive comments are part of how the committee reads demand. A proposal with five real-world use cases in the thread is measurably stronger than the same proposal with none — and the person who filed it cannot supply those use cases themselves.
Sharing the call internally is worth as much. The developers on your team who hit these bugs daily are usually not the ones watching browser vendor blogs in September.
Takeaways
- The deadline is September 23, 2026. Proposals are GitHub issues in the
web-platform-tests/interoprepository; nothing filed after that date is considered for 2027. - Check the two hard gates first: a stable spec with no outstanding vendor objections, and enough WPT coverage to score against. Use webstatus.dev to confirm in under a minute.
- Write about the divergence, not the feature. One narrow feature per proposal, with a production use case and linked test numbers.
- Search open proposals before filing. Supporting an existing issue with your use case is more effective than a duplicate.
- Pull the list from your own codebase. Grep your CSS for vendor-specific comments and your JS for user-agent branches. The workarounds you have stopped noticing are the best evidence anyone can submit.
The reason this is worth an hour of a senior developer's time is narrow but real: interoperability work compounds. Every feature that gets to consistent behaviour is a polyfill your team deletes, a branch you stop testing, and a category of bug that stops reaching your users. That is the return on filing one well-argued GitHub issue before Wednesday.
Sources
- Submit your proposals for Interop 2027 — Rachel Andrew, web.dev, September 3, 2026
- Submit your ideas for Interop 2027 — Yulun Wu, WebKit, September 3, 2026
- Interop 2026 dashboard — Web Platform Tests