今天继续来为大家解读今年的 Google I/O
在这个章节中，主要分享了 Chrome 与其他浏览器合作伙伴以及更广泛生态系统合作的方式，提出了一个新的 Web 基线的概念，目的是尽可能的消除 Web 兼容性的问题，让跨浏览器开发更简单。
旧版浏览器兼容
Web 开发已经经历了 20 年的风风雨雨，这段时间发生了非常大的变化。但有一点始终如一，就是我们一直在苦恼需要兼容哪些较老的浏览器。
在以前，浏览器版本的更新频率很低。Web 平台的功能进步缓慢，可能一年只有一次。Internet Explorer 6 到 7 之间经历了 5 年。这段时间没有新版本推出，只能一直处理 bug。但是正因为 Web 平台的进展缓慢，开发者才能够及时追踪平台的变化。
现在，浏览器可能每个月都会有新的版本，每一个浏览器版本都会带来新的功能和修复，从新增单一的 CSS 属性到庞大的 Web GPU 规范。
升级软件是一种常态，所以大部分用户会很快使用到最新版本。新功能快速上线，以前所未有的速度进入我们用户的设备。功能也变得更加容易操作和交互，这意味着它们在所有浏览器引擎中的工作方式都会相同。
现在，Firefox、Chrome 和 Safari 同时引入新功能已经是很常见的事情。比如去年，我们看到 Firefox 97、Chrome 99 和 Safari 15.4 同时推出了 CSS 级联层，大家期待已久的容器查询也在几个月后的浏览器版本中互相兼容。
这很令人兴奋，但也给开发者们带来了难题。如此多的新功能这么快的推出，我们跟得上吗？我们怎么判定能不能在生产环境中使用这些功能呢？
在以前浏览器更新缓慢的时候，开发者会依赖最老的浏览器作为基准。总有一个浏览器不会消失，我们必须基于它提供支持。为了不断推进平台的发展，我们需要达到这样一个点：那个浏览器的用户足够少，我们只提供基本的支持或使用渐进增强的方法。
- 我们需要
Internet Explorer 11(2013 年推出的已经停止更新的浏览器)消失，这样我们才能使用网格布局。 - 我们希望
Internet Explorer 9消失，因为它不支持Flexbox、CSS多列和渐变等功能。 - 我们希望
Internet Explorer 8消失，这样我们才能使用圆角和颜色的透明度。 Internet Explorer 6推出时带来了很多CSS新特性，但是有很多奇葩的Bug导致页面无法渲然。- 回到更早的时候，我们希望
Netscape 4消失，特别是那些正在实验 CSS 布局的人。因为它有一个巨大的Bug，任何元素在用户重新调整浏览器窗口时会失去之前的定位。
现在，这些浏览器已经消失了，Microsoft 去年终止对 Internet Explorer 11 的支持。所以使用浏览器作为基准已经不再适用了，所有引擎都在快速的发生变化。
解释兼容性依然艰难
虽然如此，我们仍需要解释浏览器的兼容性。我们需要告诉团队哪些特性可以使用，确保利益相关者能够理哪些功能在各个浏览器和版本中能不能用。根据 Google 的研究，开发者很难理解发生了什么以及新功能的兼容性如何，能够跟上 Web 平台的变化和使设计与应用在浏览器中工作方式相同一直都是一个挑战。
Chrome 团队在过去一年一直努力解决这个问题，在去年的 Google I/O 上也分享了一些正在做的一些事情，但是进展并不明显。
Chrome 的主要沟通渠道是 web.dev 和 developer.chrome.com，目标是让开发者能够以清楚一致的方式使用 Web 新特性，这里经常会介绍一些令人兴奋的新功能，Chrome 也希望它们能够快速的实现跨浏览器兼容。
比如，今年推出的 View transitions、Web GPU 或 popover API 可能吸引了大家的关注。在今年 Google I/O 的其他演讲中也详细介绍了这些方式，但是这也只是明确仅存在于 Chrome 中的方式。
在 web.dev 上，大家可以找到不同浏览器引擎世界中的最佳实践的指南。我们可以在支持面板清楚地看到这些特性的浏览器兼容情况。数据来自 MDN 浏览器兼容数据，Chrome 团队会积极的保证它及时更新。
在今年 Google I/O 中，介绍了一些三大浏览器引擎都兼容的 Web 新功能：
当功能互相兼容时，web.dev 会发表相应的文章来介绍它们，因为当一个特性在所有三个引擎中出现时，大家才会觉得这是一个可以在生产使用的功能。这些文章的目的也是为了告诉大家这个点。
Chrome 推出的新功能的文档也得到了加强，比如这是一个 Chrome 首推的 API 贡献在 MDN 上的文档，并在 developer.chrome.com 上记录功能的起源试用版。到了 Chrome 稳定版推出功能的时候，通常 MDN 上就会存在帮助大家了解如何使用它们的文档。
Interop 项目
Chrome 团队会重点关注多浏览器引擎的多样化 Web，其中一系列关于 Web 平台新功能的文章都会庆祝其他浏览器推出的功能。为了改进开发者生态的体验，不能闭门造车。各大浏览器厂商必须联合起来，一起改善浏览器兼容性和开发者的体验。虽然许多功能在浏览器中很快会得到实现，但许多功能在一个或多个引擎中可能会存在不可用的情况或存在重大 bug 。
Interop项目就是为了解决这个问题，Google 与来自 Mozilla 和苹果的代表以及其他合作伙伴一起工作，定义了 2022 年的一组功能，然后所有浏览器都会一起努力推出这些功能。
因为一个这样的倡议，下面一些功能在所有浏览器中都得了兼容：dialog 元素、内置拥有无障碍特性的模态和非模态对话框、新的兼容移动端 UI 的视口单位、CSS 级联层等等，这解决了开发者挣扎了多年的难题。
现在正在重复这个过程，Interop 2023 包括了更多更强大的功能。大家可以在这里了解所有包含的功能并在仪表板上跟踪我们的进展。
Chrome 团队还帮助创建了 Web DX 社区小组，目的是关注并改善 Web 平台的开发的体验。小组包括所有浏览器的代表，有两个目标:
- 澄清
Web平台的特征状态，具体来说就是说明哪些 Web 功能目前是是广泛可用的。 - 协同研究，促进所有浏览器供应商对某类问题有共同的理解。
去年，这个小组进行的研究也应用在了 Interop 2023 之中。
文档对于开发者来说是很重要的，Google 和其他公司一起资助了Open Web Dos（https://openwebdocs.org/），这个网站试图通过文档改善来 Web 平台的清晰度，也是 MDN 的主要贡献者。
Web BaseLine
Chrome 团队已经做了很多努力，在过去一年也取得了一些进展，但是我们意识到浏览器兼容性现在还是很难理解的。关于单个功能和 API 的兼容性信息也确实是存在的，但是开发者必须逐个检查每个功能甚至功能的组合，才能确保某些特性是可以跨浏览器工作的。
在开发过程中，我们需要为大量的功能确定能否兼容我们设定的浏览器基线，而且我们也必须要确定这样一个基线。为了便于大家理解，在最开始的时候我们提到了几个关键的浏览器版本，但是目前如果没有这几个关键的浏览器版本，就很难界定这个基线了。在每个项目上，团队都需要花费很多的时间来试图弄清楚从何时可以开始使用什么功能，这可能会额外消耗大量的时间。所以，我们有必要给大家提供这样的一个基线，然后帮大家来确定哪些功能是可以安全使用的，哪些需要更多的考虑才能在所有浏览器上很好的工作。几大浏览器厂商也正在积极的界定它。
它的名字就被界定为基线（Baseline），如果某个功能是基于这个基线来开发的，那么它就应该得到广泛的跨浏览器支持，大家也可以放心的使用它。
一个新特性只有在可兼容并可安全使用时才能进入基准，开发者也可以很开心的和产品运营等同学去分享，我们的网站所有的功能都处于基线之中，不用再去兼容什么 IE6 了，只需要把基线内的功能兼容好就可以了。浏览器厂商希望可以做出清晰的指导，解释哪些功能可以进入基线，以及为什么可以进入基线。浏览器厂商们的目标就是基线可以在开发者查找有关功能信息的任何地方采用（比如 MDN、Can I Use 以及 web.dev）。而且也可以供框架开发者采用，这样就可以提供浏览器兼容性的明确指示。
基线中的功能会逐渐增多，每月或每年，我们都很容易看到哪些新特性成为了基线的一部分，这些都是我们可以放心研究并使用的功能。定义好这些安全的功能基线之后，浏览器厂商就可以放心的去开发新功能，并且努力让它们成为基线的一部分，以后任何 Web 平台特性的目标都应该是成为基线的一部分。想要了解 Web 基线的更多信息，可以到这里 https://web.dev/baseline/ 了解。
最后
最后做个简单的总结，以后大家要判定一个新的 Web 特性能不能在生产环境中使用，看看它是不是被纳入到了 Web 基线的一部分就可以了。强烈不建议大家以一些老旧的浏览器（例如 IE 6/7/8）作为网站的兼容性标准了，它们的市场份额已经少的可怜，投入产出比极差，以后大家只需要根据基线兼容即可！
参考：https://youtu.be/eZa3BgGaAeA
