Interop 2027 Is Being Decided Right Now: How We Rank Browser Proposals From Our Own Build Stack
About 100 Interop 2027 proposals are on a public ranking ballot while the Interop team must finish selection before December 10, 2026. We counted the compatibility code our own site actually ships — 0 polyfills, 0 @supports gates, 1 IntersectionObserver, 4 scroll listeners — and used three filters to pick the six proposals worth ranking.
Interop 2027 Is Being Decided Right Now: How We Rank Browser Proposals From Our Own Build Stack
The Interop 2027 focus areas are effectively being chosen this month. About 100 proposals filed between September 3 and 23, 2026 are sitting on a public ranking ballot, the Interop team must finish selection before December 10, 2026, and the published scope does not arrive until February 4, 2027. For everyone who does not sit on that team, the ranking is the only lever left — sign in with GitHub, pick about ten of the hundred, positive signals only. The way to use it is not "which feature sounds exciting" but "which proposal deletes compatibility work we already pay for." We ran that test against our own production source on October 13, 2026: we counted the shims, feature gates and observers we actually ship, matched them against the open proposals, and six of them cleared our filters.
The clock, straight from the process document
The Interop 2027 proposal selection process is public, and the dates matter more than the feature lists:
| Date | What happens |
|---|---|
| September 3–23, 2026 | Proposal submission window. Focus areas are filed as GitHub issues in web-platform-tests/interop with the focus-area-proposal label. |
| Now through selection | The Firefox team's second annual public ranking: about 100 proposals, roughly 10 picks each, GitHub sign-in required. |
| Before December 10, 2026 | Proposal selection finished by the Interop team. Consensus means at least two participating organizations support a proposal and none opposes it. |
| February 4, 2027 | The scope of Interop 2027 is published. |
| February 11, 2027 | The dashboard goes live, proposal authors get feedback and the original issues close. |
Two numbers give the project its context. Interop 2026 stood at Chrome 98, Edge 98, Firefox 96 and Safari 92 on September 3, 2026 — the pass rate across the shared test suite — so the mechanisms work. And last year's ranking collected more than 1,900 responses, which Mozilla says it used both to push proposals inside Interop and to prioritize feature work in Firefox itself. That is the part worth taking seriously: this ballot is not a survey, it is input to a roadmap.
What our codebase actually says
web.dev published a coding-agent prompt for exactly this job on September 18, 2026: scan the project for polyfills, wrapper libraries, @supports blocks and custom JavaScript workarounds, match what you find against the open proposals, and sort the result by estimated code eliminated. We ran the same audit by hand against our own Astro and Cloudflare Pages site on October 13, 2026:
| Signal counted in our own source | Value |
|---|---|
Polyfills in package.json | 0 |
@supports feature gates in shipped source | 0 (38 matches exist, all inside our own articles' code samples) |
| Inline script across the 11 component and layout files that carry one | ~1,300 lines |
IntersectionObserver in shipped components | 1 |
scroll / resize listeners in shipped components | 4 |
| Explicit feature detections | 2 (requestIdleCallback in window) |
| Native media queries we lean on | 3 (prefers-reduced-motion twice, prefers-color-scheme once) |
<iframe> elements in production markup | 1 (the Google Tag Manager noscript frame) |
Image files in public/images | 610 JPEG, 0 AVIF, 0 JPEG XL |
Content-Security-Policy on the production origin | none, when checked with curl on October 13, 2026 |
The first line of that table is the finding that changed our ranking: we have almost no compatibility layer left to delete. Ten years ago an agency site carried a polyfill bundle and a wall of @supports fallbacks; ours carries neither. So a ranking built only on "how much code does this proposal remove" would be nearly empty for us — which means the useful filters for a Baseline-first stack are the other two.
Three filters, applied in order
- Does it delete code we ship today? Countable in the audit above. Rare for us, decisive when it fires.
- Have we debugged this exact cross-browser bug before? A gap we have already paid for once, in hours, on a client build.
- Can we measure the user-facing win in our own telemetry or assistive-technology testing? Layout shift, LCP, INP, or a screen reader that stops behaving differently per engine.
Anything that clears two of the three gets ranked. The rest stays unranked — which, on this ballot, is the correct way to say nothing.
The six we ranked, and the one we skipped
| Proposal (GitHub issue) | Why it cleared the filters | Verdict |
|---|---|---|
| Responsive iframes (#1443) | Filters 1 and 2. On September 26 we told readers to keep their postMessage shim because frame-sizing is Chromium-only. The proposal covers the embedding side (frame-sizing), the embedded opt-in (<meta name="responsive-embedded-sizing">) and window.requestResize(), all in CSS Box Sizing Level 4. Baseline status is Limited Availability with 20 developer votes. | Rank, top pick |
| Pausing iframe media when not visible (#1468) | Filters 1 and 3. One third-party frame is all we ship, but every client site we maintain carries chat, video or analytics frames, and an offscreen frame that keeps decoding is CPU and battery we cannot account for in our own performance budgets. | Rank |
| Progressive image rendering for JPEG XL and AVIF (#1459) | Filters 2 and 3. We measured JPEG XL transcoding on our own blog on October 9. The proposal notes progressive JPEG XL rendering already works in Firefox and Chrome but not Safari, while AVIF progressive decode is Chrome-only after the avifenc improvements — and progressive rendering was the number one reason developers asked for JPEG XL in the first place. | Rank |
| Trusted Types (#1465) | Filters 2 and 3, with an honest asterisk. We published a full Trusted Types rollout playbook on August 21, 2026, and our own production origin still answers with no Content-Security-Policy header; Lighthouse files the missing directive as a High-severity item in our own report. We are ranking the feature we have not finished adopting ourselves. | Rank |
| CSS scroll-triggered animations | Filter 1. Four scroll listeners and one IntersectionObserver are still how we do reveal-on-scroll effects. We argued back in July that native scroll-driven animations end that pattern, and scroll-triggered triggers are the missing half of it. | Rank |
JavaScript Temporal | None. We have 11 new Date( calls, all of them reading dates from content collections, with no timezone arithmetic anywhere. Temporal is a better API, but it would delete nothing we ship, so ranking it would be taste rather than evidence. | Skip |
The skip is the point of the exercise. Temporal gets cited in almost every "features I want" list, and we would like it too — but our ballot is a scarce resource, and spending one of ten picks on a library our codebase does not use makes the other nine picks mean less.
Why the coding-agent audit landed at the wrong moment
The September 18 prompt ends with "submit or upvote proposals before the September 23rd deadline," and that door is closed: proposals are in, and the open list now belongs to the selecting organizations. What is still open is the ranking, and it takes the same evidence. An agent that lists your polyfills, @supports blocks and observer-based workarounds is not giving you a refactor backlog — it is giving you the justification for ten ranked lines.
If you run it now, expect the output to sort differently from ours. A team that still ships a polyfill bundle will find filter 1 doing all the work. A team with a mature Baseline-first codebase will land where we did: few things to delete, several bugs already paid for, and a small number of proposals where the win can be measured in the same dashboard you report to clients.
FAQ
What is Interop 2027? An annual interoperability project run inside the web-platform-tests repository by representatives of Apple, Google, Igalia, Microsoft and Mozilla. Developers file focus-area proposals as GitHub issues, each organization selects and prioritizes them internally, and the final list is adopted by consensus — at least two participating organizations supporting a proposal and none opposing it. Progress is measured with the shared Web Platform Tests suite.
When are the Interop 2027 focus areas announced? Submission ran September 3–23, 2026; selection must be finished before December 10, 2026; the scope is published February 4, 2027 and the dashboard launches February 11, 2027.
How do you rank the proposals? Sign in with GitHub on the Firefox ranking page, pick around 10 of the roughly 100, and rank only features you feel positively about — unranked items are ignored, anything you rank counts as a positive signal, and rankings autosave until the process ends.
Can a coding agent tell you which proposals matter? Yes, that is what the September 18 web.dev prompt is for: scan for polyfills, wrapper libraries, @supports blocks and custom JS workarounds, match them against the open proposals, and sort by estimated code eliminated. Since the proposal window closed on September 23, use the output to rank rather than to file.
Sources
- Submit your proposals for Interop 2027 — web.dev, September 3, 2026
- Find features to support for Interop 2027 with your coding agent — web.dev, September 18, 2026
- Interop 2027 proposal selection process — web-platform-tests/interop
- 2027 Web Platform Feature Ranking — web-standards.dev
- Responsive iframes — interop issue #1443
- Progressive image rendering for JPEG XL and AVIF — interop issue #1459
- Pausing iframe media when not visible — interop issue #1468
- Trusted Types — interop issue #1465
Related reading on mintec.co
- Chrome 154 takes over iframe sizing — and where to adopt it
- Chrome 155 decodes JPEG XL: we measured it on our own blog
- Trusted Types is Baseline: the frontend guardrail you need before innerHTML
sizes=autois Baseline — and our own blog ships no srcset at all- Native scroll-driven animations in CSS: the end of IntersectionObserver for reveals
- Video and audio lazy loading: the
loadingattribute finally covers media
Frequently Asked Questions
What is Interop 2027?
Interop 2027 is the annual interoperability project run inside the web-platform-tests repository by representatives of Apple, Google, Igalia, Microsoft and Mozilla. Developers file focus-area proposals as GitHub issues, each organization selects and prioritizes them internally, and the final list is adopted by consensus — at least two participating organizations supporting a proposal and none opposing it. Progress is measured with the shared Web Platform Tests suite and published on a public dashboard.
When are the Interop 2027 focus areas announced?
The selection process document sets three dates: proposal submission ran from September 3 to September 23, 2026, proposal selection must be finished before December 10, 2026, the scope of Interop 2027 is published on February 4, 2027, and the dashboard launches on February 11, 2027.
How do you rank the Interop 2027 proposals?
Sign in with GitHub on the Firefox team's public ranking page and pick around 10 of the roughly 100 proposals. Only rank features you feel positively about, because anything you rank is counted as a positive signal and unranked items are ignored. Rankings autosave and can be edited until the process ends, and last year more than 1,900 rankings were submitted.
