Web互操作性迎来新突破！Interop 2025聚焦View Transitions API、Navigation API等，提升WebAssembly性能。重点关注CSS锚点定位、Core Web Vitals API，解决Flexbox和Grid布局兼容问题。Storage Access API提升隐私，修复mutation事件，加速WebRTC标准化，共建更流畅、安全的Web体验！
译自：Interop Unites Browser Makers To Smooth Web Inconsistencies
作者：Mary Branscombe
在过去的四年里，主要的浏览器厂商、Web 标准制定者以及浏览器引擎的其他贡献者齐聚一堂，共同改进 Web 的互操作性，协调对不一致的浏览器实现的改进，从而更容易创建在每个浏览器和不同设备上以相同方式工作的网站和应用程序。
“当你询问开发者他们最大的痛点时，通常与 Web 平台固有的挑战有关：它不是由单个供应商提供的。Web 由多个供应商提供，这是一件非常独特的事情，”Google Web 平台部门的 Kadir Topal 指出。“这导致了开发者最大的痛点：事物在不同浏览器中的工作方式不同。”
许多互操作性工作都用于改进已经指定和发布的特性，但越来越重要的是，确保较新的特性在发布时具有互操作性。
正如 Google Web 平台团队的软件工程师 Philip Jägenstedt 所说，“我们在 Interop 中有两条腿：修复旧的，并确保新的将来不需要修复。”
以 View Transitions API 为例，它是 2025 年的重点关注领域之一。它尚未在所有浏览器中发布，因此还不是 Web 平台 Baseline 的一部分。包含它的目标是将其引入 Baseline，Interop 确保测试足够彻底。“即使我们不确切知道开发者会遇到什么问题，我们也会对其进行非常好的测试，并确保所有测试都在所有浏览器上通过，因此我们可以比过去更有信心，他们不会遇到那么多问题。”
“我们在 Interop 中有两条腿：修复旧的，并确保新的将来不需要修复。”
– Philip Jägenstedt, Google Web 平台团队
Interop 最初的推动力来自于“令人惊讶的是，开发者最沮丧的很多事情并不是我们所想的事情——你无法设置按钮的样式，或者我们没有容器查询——而是每个编写代码的人都会遇到的互操作性问题，”Igalia 开发者倡导者 Brian Kardell 解释说。更大的挫折是由于“应该长时间工作的东西只是无法互操作。”
多亏了 Interop，“那些永远存在的事情确实得到了修复，”Topal 说。“这些事情越来越少，因此它让我们有更多机会专注于积极主动。”
每年关注的领域都是从研究、调查和开发者反馈中选择的，并且进度的衡量标准不是单个浏览器可以通过这些领域中的多少 Web 平台测试 (WPT)，而是所有浏览器中通过的测试数量，这是一个逐年稳步提高的最终结果。
早在 2021 年，这个互操作性得分开始时略低于 65%，结束时略低于 89%。对于 Interop 2024，所有 17 个重点关注领域的两项指标的最终得分都很高，四个主要浏览器达到 99%，通用互操作性得分达到 97（高于最初的 62）——是迄今为止最高的。“所有领域都取得了显着进步，”Igalia Web 标准倡导者 Eric Meyer 说。
“所有领域都取得了显着进步。”
– Eric Meyer, Igalia Web 标准倡导者
根据 Jägenstedt 的说法，今年的 Interop 范围“相当大”。它还包括有更多改进空间的重点关注领域。
27.5% 的初始互操作性得分并不意味着 Web 突然变得更加糟糕。Interop 2025 中的 19 个重点关注领域包括各种特性，其中所有浏览器都分别获得了合理的分数，但也都有不同的领域需要赶上，一个或两个浏览器尚未完全实现的特性（或者在某些情况下，根本没有实现，例如导航 API），以及特性本身或其测试相对较新的领域（例如 WebAssembly 重点关注领域）。 它们还包括一些主要功能，如锚点定位、视图转换和导航 API。Meyer 指出，虽然该规范相对较新，“但对解决该规范所解决问题的需求一直存在”。
让 Web 开发者能够更好地处理复杂 Web 应用程序中的导航，而无需劫持后退按钮，这将使开发者和用户都更满意。
这对于框架和复杂的 Web 应用程序尤其有用，这些应用程序会拦截导航并更新页面，而不是加载新页面。Jägenstedt 解释说：“Web 现有的用于处理历史记录的 API（如后退和前进）充满了 Bug 和边缘情况，我们无法修复，因为这会破坏现有站点。”
“导航 API 是一个干净的模型，它可以真正工作，没有这些 Bug，开发者可以可靠地拦截导航并更新页面，而不是进行完全重新加载。” 目前，框架和应用程序是手动执行此操作的，并且可能在执行方式上存在 Bug。
通过视图转换，开发者可以在 Web 应用程序中不同的视图和状态之间实现平滑的动画转换。可以想象一下电子书，其中的页面像真正的书一样翻页，或者博客，你可以应用与幻灯片中相同的滑动和交叉淡入淡出转换，当你打开和关闭文章或单击图像以查看更大的版本时。（Meyer 指出，如果这听起来很烦人，告诉你的浏览器你更喜欢减少动画效果会关闭大部分此类效果。）
微软 Edge 的产品组经理 Kyle Pflug 建议说：“更重要的是，这使我们更接近于在所有浏览器中实现跨文档转换，这将最终使开发者更容易使用多页面 Web 应用程序，浏览器对处理多页面 Web 应用程序进行了极好的优化。”
锚点定位是另一个较新的功能：将其包含在 Interop 中意味着到今年年底，所有浏览器都应该具有可互操作的实现，以创建工具提示、锚定侧边注释、锚定到页面上某些内容的弹出窗口以及其他链接内容的方式。
Meyer 解释说：“你可以将你想要弹出的内容放在文档的末尾，例如脚注，当有人将鼠标悬停在右上标上时，内容会定位在它旁边，然后当鼠标移开时，弹出窗口会消失，脚注会回到末尾。” “如果将锚点定位与滚动转换结合使用，则可以使用侧边注释执行相同的操作。你无需确切知道该内容在屏幕上的哪个位置；你只需说‘将自己放在该内容下方’。”
“一旦 CSS 锚点定位可以互操作，开发者就不必使用工具提示库或维护自己的工具提示库。”
– Kyle Pflug，微软 Edge 产品组经理
Pflug 补充说：“一旦 CSS 锚点定位可以互操作，开发者就不必使用工具提示库或维护自己的工具提示库。显示和定位工具提示将变得简单、快速，并且不需要 JavaScript，”他还指出，“改进 <details> 元素所做的工作将使开发者能够仅使用 HTML 和 CSS 来显示应用程序中类似手风琴的组件并为其添加动画效果。”
Jägenstedt 预测，锚点定位还可以实现 Web 开发者非常想要的东西：“可自定义的 <select> 元素，你可以在其中放置任何你想要的内容并查看你的选项。”
“如果我们问 Web 开发者他们不喜欢 Web 的什么，他们会说‘表单样式’。如果我们说‘你是什么意思？’他们会说‘select’。如果我们说‘你是什么意思？’他们会说‘我希望我的每个选项旁边都有小旗帜’。他们想要可自定义的 select：这非常接近 [开发者] 痛点的前沿，而锚点定位是实现这一目标的关键。”
Core Web Vitals API 来自 Google 衡量网页用户体验的工作，例如性能和交互性。Google 搜索已将这些质量信号用于页面排名，但性能是大多数 Web 开发者关心的事情，如果浏览器可以为你提供有关页面加载速度、用户尝试单击或滚动时页面的响应速度或页面布局是否在不同元素加载时跳动的关键指标，这将非常有用。
让 Firefox 和 Safari 提供与开发者已经在 Chromium 浏览器中获得的相同指标的方法将帮助开发者检查性能在不同浏览器和设备上是否一致。
“性能至关重要：当 Web 性能提高时，人们使用网站的幸福感也会提高。”
– James Graham，Mozilla Web 兼容性工程师
“如果我们有这些非常棒的性能监控 API，并且它们在各种浏览器中都能很好地工作，那么 Web 作者就可以更容易地检查他们的网站在各种浏览器中的性能。性能至关重要：当 Web 性能提高时，人们使用网站的幸福感也会提高，”Mozilla Web 兼容性工程师（以及 WPT 项目的长期成员）James Graham 指出。
与 JavaScript 一样，CSS 越来越多地接收到原生功能，而这些功能曾经需要工具，例如 Sass（以及额外的构建步骤）。当您使用复杂的 CSS 规则时，作用域允许您仅将样式应用于页面的某些区域。
“Vue 和 Svelte 使您可以在组件中编写 CSS，并且它仅适用于该组件，并且这种作用域通常通过生成一个类并将其应用于每个事物来完成，但是如果人们不需要使用 CSS 的构建工具，那就太好了，”Ecma 主席 Daniel Ehrenberg 解释说。“让您使用浏览器支持的语言进行创作总是会带来好处：当以原生方式完成时，该功能会更好。”
WebRTC（实时通信）是 Web 上视频会议的基础。您无需为收到会议邀请的每项服务都使用原生应用程序，只需单击 URL 即可加入视频通话。但 Graham 指出，“对标准的遵守程度不一定像平台的其余部分那样好。” 特别是，使用 WebRTC 的端到端加密依赖于某些但并非所有浏览器中存在的专有系统。“现在我们有了一个标准。”
RTCRtpScriptTransform API 允许脚本修改通话中的媒体流。Graham 将其描述为端到端加密视频通话的先决条件之一。
重点领域还包括将 WebRTC 数据通道传输到 worker，从而将数据处理从主线程中移出。WebRTC 在未来几年将需要更多互操作性工作，但这是它首次成为 Interop 的一部分，“我们迈出第一步真是很有希望。”
Web 上的视频会议也将受益于背景滤镜重点领域。如果您决定模糊您的视频背景，这就是它的完成方式。但它还可以处理在对话框打开时应用于网页的效果，无论是模糊访问者登录时的文章，还是拥有浮动在页面上而不完全遮挡它的工具。
“您可能有一个始终位于页面顶部的粘性标题，无论您向上或向下滚动多远，但您可能希望它后面的所有内容都是模糊的，”Meyer 建议。“您可以将您想要的任何滤镜应用于它后面的任何内容。”
关于第三方 Cookie 的持续争论提醒人们注意安全性、隐私和便利性之间的权衡。
关于第三方 Cookie 的持续争论提醒人们注意安全性、隐私和便利性之间的权衡。当这意味着浏览器限制 Web 开发人员以前可以做的事情时，这可能会引起争议。
浏览器希望能够对存储进行分区，以便更难跟踪用户。在一个站点上设置第三方 Cookie，而另一个站点可以访问该 Cookie，这是一种非常容易的方式来跟踪用户在 Web 上的活动。
“不幸的是，事实证明一些重要的工作流程依赖于这项工作，”Graham 解释说——特别是身份验证。“如果您有一个单点登录提供程序，您不希望每次不同的子域都必须再次登录，因为这会破坏整个意义。”
同样，如果用户想要在嵌入在网页上的 iframe 中的 YouTube 视频上点击“喜欢”，他们可能不想每次都登录 YouTube。
Storage Access API 允许站点选择加入 Cookie 的未分区存储（如果需要）。“对于绝大多数情况，我们可以根据哪个站点设置了该用户数据来很好地对用户数据进行分区，但在极少数情况下，将 Cookie 发送到您的身份验证提供程序是工作流程中非常重要的一部分，您可以说，‘没关系，将这些 Cookie 发送到我的身份验证提供程序。’”
存储访问可能是一个低级细节，但 Graham 预计，一个使与服务交互更加无缝，而不会泄露大量用户数据的 API，所有浏览器都很乐意实现，从而真正改善隐私。“如果您开始破坏用户工作流程，那么我很可能会准备放弃隐私，因为我需要这个工作流程才能工作，但这不是我们希望人们必须做出的权衡。”
早期的 Interop 中，长期存在的跨浏览器布局兼容性问题已经大大减少，但 Web 兼容性重点领域仍将是 Interop 的常规组成部分。“这是一个错误或较小功能的集合，其动机是我们已经看到它以某种方式破坏了真实的网站。” Graham 认为 Interop 的价值在于“它提供了一个跨整个平台修复错误的框架，同时也激励了新功能的出现。”
Interop “提供了一个跨整个平台修复错误的框架，同时也激励了新功能的出现。”
– Graham, Mozilla
Flexbox 和 grid 重点领域已经在 Interop 中存在了几年（每年都有显著的改进）。Pflug 称它们为“现代布局的极其重要的构建块，虽然它们旨在让开发人员易于使用，但浏览器引擎需要处理大量的复杂性。” 他补充说，“flex 和 grid 的尺寸和放置算法非常复杂，并且必须在任何地方工作：在表格、多列、列表项中，相互嵌套，具有不同的书写模式，其中包含图像，当您调整页面大小时，以及溢出内容等。”
仍然有一些零散的问题需要整理，Edge 团队正在努力修复一个微妙的问题，即静态定位和对齐会影响有和没有 grid 的 flexbox 场景。
“如果一个 absolute-positioned 或 fixed-positioned 元素使用其 static position 进行定位，则该静态位置会将对齐考虑在内。Alignment properties 可以采用一个 'safe' 关键字，该关键字表示如果被对齐的项目溢出对齐容器，浏览器应将该项目对齐为 'start' 对齐（以避免视口左边缘的溢出）。”
但是，Edge 和 Chrome 目前没有考虑到这种情况下的“safe”，并且事实证明规范并不完全清楚应该发生什么，这导致 flex/grid 测试用例失败，他解释说。 这是一个有点微妙的例子，许多开发者可能不会遇到，但它很好地展示了许多互操作性工作是如何进行的。在实践中，改进互操作性需要追查这样的极端情况，以确保它们得到一致的处理，这样开发者在尝试使他们的代码在所有浏览器中工作时，就不必担心令人困惑的障碍。
同样，有一个重点领域是确保所有浏览器删除一两个功能。用于监视 DOM 更改的三个旧的 mutation 事件已经被弃用十多年了，并被更有用的 Mutation Observer API 所取代。
同样，浏览器制造商至少在 15 年前就认为特定于供应商的前缀是个坏主意。今年，Interop 将通过确保开发者可以使用 text-decoration CSS 属性（已在足够多的浏览器中实现，可以算作 Baseline 中广泛可用）来设置装饰线的样式和颜色（如下划线文本或删除线），而无需在 Safari 中使用供应商前缀，从而在替换它们方面做更多的工作。
“这些小事情经常被忽视，因为‘哦，这很简单，我们可以在业余时间做’；现在它在要做的事情的清单上。”
– Meyer, Igalia
Meyer 很高兴看到 Interop 包含这样的清理工作：“这些小事情经常被忽视，因为‘哦，这很简单，我们可以在业余时间做’；现在它在要做的事情的清单上。”
这也提醒我们，自从网络早期的“浏览器大战”以来，我们已经走了多远：Graham 称 CSS Zoom 重点领域是“本应该更快完成的典型例子”。
Microsoft 在 CSS 转换可用之前在 Internet Explorer 中构建的一个专有功能——为了给 Excel 的 Web 版本提供与桌面应用程序相同的缩放体验——被逆向工程并在 WebKit 中实现（很多 Mac 用户需要 Office），但它仍然不是一个标准，Mozilla 支持它的尝试修复了一些网站，但破坏了另一些网站。
“我们与 Google 经历了一个完整的流程，看看是否可以在没有人希望将其标准化的情况下将其从平台上删除。结果证明，不，我们不能删除它——但是如果我们一起努力，我们可以找到一种在以前无法做到的时候对其进行标准化的实用方法。”
现在，W3C CSS 工作组中有一个新的规范，并且所有浏览器现在都在实现它。
Interop 中的调查领域着眼于如何包含已为 Interop 提出的但无法测试的内容。有时是因为规范仍在快速变化（或者没有特定功能的规范），这必须返回到相关的标准组。
有时是因为需要编写新的测试，但通常是关于弄清楚如何为 WPT 尚未具有测试基础设施的功能创建和运行测试，特别是对于移动或游戏设备。许多测试着眼于页面内容，但这不足以测试，例如，触摸滚动如何执行。这必须在浏览器堆栈的不同层完成。
“事实证明，移动设备上存在许多桌面设备上不存在的技术挑战。”
– Graham, Mozilla
“当这么多浏览发生在移动设备上时，你为什么要在桌面上运行所有测试？事实证明，移动设备上存在许多桌面设备上不存在的技术挑战，”Graham 指出。在模拟器或移动模拟器甚至在移动设备上运行测试可以解决这个问题，尽管代价是增加了一层复杂性。
“但事实证明，我们依赖于测试自动化的东西不一定在移动设备上有效。”一些测试依赖于将视口设置为特定大小。这在移动设备上并不总是可能的。Gecko 在渲染引擎中有一个特定的测试模式，可以更好地控制视口等选项；其他浏览器是否需要类似的东西？
“我们需要弄清楚所有这些技术挑战，看看我们甚至可以做些什么可以在所有浏览器上工作。”
这就是为什么移动测试是 2025 年的调查领域之一，这可能允许像指针事件这样经常被提出的功能最终成为 Interop 的重点领域，尽管具有讽刺意味的是，它们可能只在移动设备上进行测试——因为虽然 Windows 触摸笔记本电脑相对常见，但对于桌面 Safari 来说，这不是一个选择。 这种方法在过去几年中运作良好，调查研究使得下一次能够关注新的领域。Interop 2024 包含一个关于 Wasm 的调查领域，因为 Wasm 和 JavaScript 的测试都是在 WPT 之外完成的，而 Interop 关注的是在 WPT 基础设施上运行的测试。
今年的 Interop 包含一个 Wasm 重点领域，涵盖了诸如提供 WebAssembly 可调整大小的缓冲区之类的内容。
由于这项工作，今年的 Interop 包含一个 Wasm 重点领域，涵盖了诸如提供 WebAssembly resizable buffers 和等效于 JavaScript 字符串处理原语的内容，这样开发人员就不必编写相同的粘合代码来一遍又一遍地导入它们。
这些大型复杂领域可能会不断出现。Interop 2023 中的可访问性调查建立在 WebDriver 扩展之上，该扩展允许测试更多的可访问性堆栈，并创建新的测试和基础设施来运行它们，因此 Interop 2024 可以包含一个可访问性重点领域，最终所有浏览器都通过了 1000 个测试中的 998 个。
今年还有另一项可访问性调查，同样着眼于如何进一步扩展可以测试的可访问性功能。在一个相关领域，WebVTT 调查领域正在研究为什么主要的视频网站不使用此标准来显示字幕和其他视频旁边的文本——这对于可访问性工具来说很容易使用，并且支持画中画，但浏览器之间的实现差异太大而无法使用。
Interop 2025 中的隐私调查领域是对浏览器隐私功能如何在不同浏览器实现非常不同的保护措施时进行测试的早期观察。Pieters 将其描述为“寻找共同点并了解如何测试各种与隐私相关的标准。”
Interop 2025 中的模块重点领域涵盖了 Ehrenberg 称之为 ECMAScript 中正在进行的更广泛的模块工作的“一小部分”：具体来说，Import Attributes 功能为浏览器（或捆绑工具）提供了有关模块的更多信息，例如它是否是 JSON（或其他类似 CSS 的东西），因此它可以有效地捆绑它，并在模块被篡改并试图加载其他代码时保护你。
这是大多数浏览器才刚刚开始实现的功能：“它已在 HTML 规范中落地，并且将其完全推广给所有人将非常棒。”
这里 Interop 的工作专门关注 JSON 导入。这是因为建议将其作为 Interop 研究领域的 Web 开发人员所要求的，并且这是一个很好的例子，说明 Interop 如何既提供重点，又阻止了可能看起来较小的问题从雷达下溜走。
由于 Web 平台中存在大量功能（取决于你如何计算子测试，WPT 最多有 200 万个测试来覆盖这些功能），因此总会有浏览器无法完全互操作的领域（仅 CSS 工作组就有 3,000 多个未解决的问题），并且 Interop 在很大程度上是一种以务实的方式解决该表面积的设定优先级的方式。
“我们有这些大规模的测试。错误就在其中，因此你可以直接修复它们，”但 Graham 指出了这种幼稚方法存在的多个问题。不期望浏览器通过每个测试。即使是 Google 的资源也不是无限的，并且浏览器未能通过的许多测试对 Web 用户没有影响（例如，由于隐私原因而弃用的环境光传感器 API 的测试）。
此外，浏览器工程师仍然是希望从事维护以外工作的开发人员。“如果你只做这些事情，那会让人感到沮丧，”Kardell 警告说。“当你可以花时间使很多人都会感到非常兴奋的锚点定位工作时，你不会想花两个月的时间来修复对互联网上的任何人都没有任何影响的最后一个表格错误。”
“Interop 的重点是选择每个人都可以同意的非常重要的领域，值得今年追求……”
– Graham, Mozilla
“Interop 的重点是挑选出每个人都认为真正重要的领域，这些领域值得今年去努力，我们应该作为 Web 平台社区共同努力，使其变得更好，”Graham 解释说。“我们已经研究了这些测试，并一致认为它们是有意义的测试，是作者真正想要的。因此，通过这些测试，我们最终应该得到非常可靠的实现，这不仅对让 Web 开发者满意很重要，而且对使用 Web 的人来说也很重要。”
当然，总有一些 Web 开发者希望看到的进展没有被纳入 Interop（例如，Temporal JavaScript 功能不在其中，MathML 问题也没有列入其中——这项技术仍然进展缓慢），并且尚未在调查领域中得到解决。
“我们一直听到开发者希望看到数百个功能成为 Interop 工作的一部分，”Pflug 指出，称优先级排序是一个“重大挑战”。
不同的参与者选择重点关注的领域来支持：展示数据以表明需要改进的地方、为什么应该优先考虑以及是否存在正确的测试来验证在这方面的工作实际上会使 Web 具有更好的互操作性。
“支持一个重点领域需要在此过程中提供支持性证据，说明为什么需要改进该重点领域，以及与其他领域相比，为什么它是一个优先事项。它还伴随着定义 Web 平台测试的责任，以验证这项工作确实使 Web 更加兼容。”
详细的讨论、否决，甚至是谁支持哪些领域都保持私密。一些 Web 开发者对此感到沮丧（并且很明显会试图从包含和未包含的内容中得出关于浏览器开发政治的结论），但这是目前浏览器公司之间达成共识所需要的，这些公司仍然彼此竞争。
“在现代生活中，Web 以某种方式存在于一切事物中，因此范围非常广泛。”
– Brian Kardell, Igalia
“Web 平台的用例实际上是所有事物，而 Web 的利益相关者是每个人。在现代生活中，Web 以某种方式存在于一切事物中，因此范围非常广泛，”Kardell 补充道。“老实说，它能发展到今天这种程度真是令人惊讶和美妙，同时也令人有些恐惧！Interop 的工作是以某种方式简化这个维恩图，并将所有这些形状合并成一些漂亮的重叠努力，这出奇地困难，而且说实话，让很多东西都处于不利境地，但庆祝我们完成的所有这些事情真的很好。”
“那些没有被选择的东西：我在委员会里，我知道发生的讨论，它们没有被选择是因为它很复杂。”
“Interop 是一个由少数组织领导的过程，”Ehrenberg 同意，“但我认为这是必要的，因为他们正在做出的这些是技术上非常详细的决定，我们不能只是进行投票。这些决定还涉及承诺资源，因此承诺资源的人需要参与决策。”
Microsoft 和 Google 都谈到希望提高流程的透明度，并且 Edge 的 Top Developer Needs dashboard 是一项尝试，旨在跟踪长期存在的开发者抱怨（其中一些确实成为 Interop 中的重点领域）。
“Shruthi Sreekanta 说：“我们努力公开设计。我们认为公开辩论不仅仅是一种副作用：它们是使 Web 变得更好的一个非常重要的组成部分。”她是 Google 从事生态系统战略的技术经理。但她欣然承认“共识是该过程中非常有价值的一部分。”
仅仅因为一个提案没有成为 Interop 的重点领域（也许是因为一个浏览器正忙于处理一个不同的子系统，这意味着要做两次工作）并不意味着其他浏览器现在不能在知道存在问题的情况下继续处理该功能。
事实证明，让浏览器制造商就这些优先级达成一致会带来意想不到的好处，Mozilla Web 标准工程师 Simon Pieters 建议说。“实际上，我们在我们工作的一部分事情的路线图上保持一致，这对浏览器供应商和 Web 开发者都有好处，因为如果每个人都在同一年实现它们，他们就可以更快地开始使用给定的功能。”
“Interop 实际上正在改变 Web 的现实。”
– Kadir Topal, Google Web 平台
多个浏览器实现一个功能意味着多个团队从不同的角度审视同一个规范，这是发现规范是否足够清晰以及测试是否真正涵盖正确内容的最佳方式。“每个参与者都带着不同的先验知识、背景和经验参与进来，当你把这些东西结合在一起时，你会发现你可能会错过的事情，”Graham 补充道。
规范会随着每次实现而改进，当出现问题并且规范需要澄清或测试需要更改时，相同的浏览器工程师仍然会被分配到该项目，并且足够接近这项工作，以便能够更新他们的实现以匹配——这意味着功能不仅可以更快地发布，而且可以实现互操作。
“互操作性实际上正在改变 Web 的现实，”Topal 认为。在过去的二十年中，Web 开发人员一直没有好的方法来请求浏览器供应商优先发布给定的技术，而 Interop 为他们提供了一个场所，Jägenstedt 同意。“现在有许多功能已经成为 Web 平台的一部分，而以前没有，因为有人花时间发送提案，我们对此进行了研究，并集体决定，是的，这是一个优先事项。”
从理论上讲，互操作的浏览器功能应该遵循一个逻辑路径，从规范到在 30 个月的强大跨浏览器支持后准备好用于主流用途，年度 Interop 流程和 Baseline 的定期更新是此过程中的各个阶段。但在实践中，事情很少如此简单，但协作的 Web 平台测试项目是所有这些不同阶段的基础。我们将在以后的文章中深入探讨这一点。