你肯定遇到过这种情况：一个页面在 Chrome 上跑得好好的，在 Safari 上要么布局错位，要么某个 API 直接报错。你打开 caniuse 一查，发现 Safari 不支持。你心里骂了一句，然后加了一堆 polyfill 和浏览器检测代码。
这个折磨了前端开发者二十年的问题，正在被一个叫 Interop 的项目系统性地解决。2026 年 9 月 3 日，苹果 WebKit 团队正式启动了 Interop 2027 的议题征集。这不是一个普通的开源项目------它是苹果、谷歌、微软、Mozilla 和 Igalia 五大浏览器厂商第一次坐到同一张桌子上，承诺一起修同一个东西。
一、Interop 是什么？为什么它比任何单个浏览器更新都重要
先讲一个反直觉的事实：你遇到的绝大多数浏览器兼容性问题，不是技术做不到，而是没人愿意先做。
假设 Chrome 实现了一个很酷的 CSS 特性，Safari 觉得"这个跟我没关系"，Firefox 觉得"等标准再稳定一点再说"。结果就是：你用不了------因为你的用户里总有人用 Safari，总有人用 Firefox。
单个浏览器的更新解决不了这个问题。只有所有浏览器厂商坐下来，说"我们今年一起把这 15 个东西修了"，这个问题才能解决。
这就是 Interop 做的事。
Interop 项目始于 2022 年 ，由苹果、谷歌、微软、Mozilla 和 Igalia 联合发起。每年，这些厂商会共同确定一批影响 Web 开发的关键兼容性领域，然后各自在自己的浏览器里实现和修复，目标是让这些功能在所有主流浏览器上表现一致。
关键机制是"自动化测试" 。每个被纳入 Interop 的功能都有对应的 Web Platform Tests（WPT）。厂商的进度不是靠"我们觉得修好了"来汇报的，而是靠自动化测试的通过率来衡量的。
2026 年的成绩单是这样的：Chrome 和 Firefox 以 99% 的完成率收官，Edge 和 Safari 达到 98% 。这意味着，被 Interop 2026 选中的那些功能，在五大浏览器上的表现已经几乎完全一致了。
Interop 2026 的成果包括：Safari 率先实现了 contrast-color()、媒体伪类、shape() 和 Scoped Custom Element Registries；容器查询和锚点定位在所有浏览器上达成一致；滚动驱动动画和 View Transitions 也完成了跨浏览器对齐。
你现在的项目里，有多少"浏览器检测代码"是因为这些兼容性问题写的？
二、Interop 2027 在征集什么？
2026 年 9 月 3 日，Interop 2027 的提案征集正式开放，截止日期是 9 月 23 日。
苹果 WebKit 团队在征集公告中明确了几条提案标准：
第一，必须是稳定、成熟的 Web 标准。 还在草案阶段、或者有厂商明确反对的特性，不适合纳入。Interop 的目标不是推动新标准，而是让已经稳定的标准在所有浏览器上表现一致。
第二，必须具备可测试性。 提案需要有对应的 Web Platform Tests，否则无法量化进度。
第三，每份提案应聚焦 1 个明确的互操作性问题，或一组范围较窄的相关特性。 不要提"CSS 排版"这种大主题，要提"font-size-adjust 在移动端 Safari 上的计算值不一致"这种具体问题。
过去几年，Interop 已经覆盖了 15 个以上的关键兼容性领域 ，包括 CSS Grid、容器查询、锚点定位、滚动驱动动画、View Transitions、:has() 选择器等等。2027 年的征集窗口只有 20 天------9 月 3 日到 9 月 23 日。通过后，最终范围将在 2027 年 2 月初公布。
三、2027 年的候选方向：哪些"老毛病"可能被修？
虽然 Interop 2027 的最终范围要到 2027 年 2 月才公布，但根据 2026 年的遗留问题和社区讨论，有几个方向是大概率会被纳入的：
1. Safari 上的 -webkit- 前缀问题
这是前端开发者最熟悉的"老冤家"。很多 CSS 属性在 Safari 上必须写 -webkit- 前缀才能生效，比如 -webkit-user-select、-webkit-backdrop-filter、-webkit-line-clamp。Interop 2026 已经在处理一部分前缀问题，但这个问题不可能一年修完。
2. font-size-adjust 的跨浏览器计算差异
WebKit 团队在提案指南中专门举了这个例子：同一个 font-size-adjust 值，在不同浏览器上算出来的实际字体大小可能不一致。这种问题对排版要求高的页面来说非常致命。
3. Popover API 和 popover 属性的行为差异
Popover 是 2025-2026 年最受关注的新 HTML 特性之一。但它在不同浏览器上的 light dismiss 行为、焦点管理、嵌套 popover 的处理上仍有差异。
4. View Transitions 在跨文档导航中的兼容性
View Transitions API 在 SPA 内部导航中已经比较成熟，但在跨文档（MPA）导航中的行为在不同浏览器上还不一致。
5. :has() 选择器的性能表现差异
:has() 的语法已经跨浏览器支持了，但它在不同浏览器引擎中的性能表现差异很大。在某些浏览器上，复杂的 :has() 选择器会触发整树重排。
四、为什么这件事对普通前端开发者至关重要？
你可能觉得："Interop 是浏览器厂商之间的事，跟我写业务代码有什么关系？"
关系比你想象的大得多。
1. 你的 polyfill 代码可以删了
如果你做过"在 Chrome 上能跑，在 Safari 上要加 polyfill"的兼容性处理，那些代码很可能是因为某个功能没有被 Interop 覆盖。Interop 每覆盖一个领域，你的 polyfill 就少一个。
2. 你的"浏览器检测"逻辑可以简化了
很多项目里有 if (isSafari) { ... } else { ... } 这种逻辑。Interop 的目标就是让这种检测变得不必要。
3. 你的测试矩阵可以缩小了
如果五大浏览器在关键功能上表现一致，你的跨浏览器测试就不再需要"每个浏览器单独测一遍"。一个 Playwright 测试可以在所有浏览器上跑同样的断言。
4. 你可以放心使用新特性了
以前你看到一个新 CSS 特性，第一反应是"Safari 支持吗？"现在你可以先看它有没有被 Interop 覆盖。被 Interop 覆盖的功能，意味着所有浏览器厂商都承诺在一年内达成一致。
五、你也能参与：20 天窗口，提交一个提案
Interop 2027 的提案征集是对所有开发者开放的。你不需要是浏览器厂商的员工，也不需要是标准委员会成员------任何开发者都可以通过 GitHub 提交提案。
怎么提交？
- 打开 Interop 2027 的 GitHub 仓库
- 创建一个新的 issue
- 描述你遇到的问题：是哪个 Web 标准？在哪些浏览器上表现不一致？有没有对应的 WPT 测试？
- 你还可以通过评论支持已有的提案
提案被采纳后会发生什么？ 各大浏览器厂商会在 2027 年把修复这个兼容性问题作为优先事项。你的一个 issue，可能改变整个前端生态。
征集窗口只到 9 月 23 日。 如果你在过去一年里被某个浏览器兼容性问题折磨过，现在就是提交它的最佳时机。
六、更大的图景：Web 正在变成"一个平台"
Interop 项目的深层意义，远不止"修几个兼容性 bug"。
它标志着 Web 平台从"各浏览器厂商各自为政"走向了"联合治理"。
过去二十年，Web 开发者的工作方式一直是"面向浏览器编程"------你写的不是 Web 标准，你写的是"Chrome 能跑、Safari 勉强能跑、Firefox 需要加前缀"的代码。
Interop 正在改变这件事。当五大浏览器厂商承诺"我们今年一起把 15 个东西修了"，当自动化测试成为衡量进度的唯一标准，当所有厂商的完成率都达到 98% 以上时------Web 正在变成一个真正统一的平台。
这对前端开发者意味着什么？
你不再需要为"在 Safari 上能不能跑"而焦虑。你不再需要在项目里维护一堆浏览器检测代码。你不再需要因为"某个功能 Safari 不支持"而放弃使用它。
你只需要写符合标准的 Web 代码。剩下的，交给 Interop。
写在最后
2026 年 9 月 3 日，Interop 2027 的提案征集正式开放。截止日期是 9 月 23 日，窗口只有 20 天。
Interop 2026 的成绩单是：Chrome 和 Firefox 99%，Edge 和 Safari 98%。被选中的功能在所有主流浏览器上几乎完全一致。容器查询、锚点定位、滚动驱动动画、View Transitions------这些曾经"在 Safari 上要加前缀"的功能，现在可以放心用了。
Interop 2027 会修什么？取决于你提了什么。
如果你在过去一年里被某个浏览器兼容性问题折磨过，去 GitHub 提一个 issue。你的一个提案，可能让明年所有前端开发者少写一堆 polyfill。
Web 正在变成"一个平台"。而你，可以参与塑造它。
评论区聊聊：你最近一次被浏览器兼容性问题坑是什么？你会去提 Interop 2027 的提案吗？