欢迎来到第二期 Chrome Dev Insider，我们将在此分享社区和 Chrome 的最新动态。这是新一期内部故事，讲述了我们如何开展工作，并简要介绍了您应关注的一些最重要的更新。
我是 Rachel Andrew，Chrome 开发技术推广团队的成员，也是 web.dev 和 developer.chrome.com 的内容主管。我从事 Web 开发工作已有 20 多年，专注于开放式 Web 标准和 CSS，并且是 CSS 工作组的成员。
两个月前，我们举办了 Google I/O 大会，并在会上分享了一些最重要的更新，介绍了我们如何支持开发者打造更快、更强大的 Web，同时确保用户信息的安全和私密性。
我们很高兴社区注意到了，团队正在努力支持网页上更多的 CSS 和界面功能。在本期 Chrome Dev Insider 中，我们将带您深入了解这项工作的幕后人员、我们如何努力为 CSS 和界面开发者提供支持，以及未来的发展方向。因此，我很高兴能主持本期“内部人士”。
新闻报道
在第一期 Chrome Dev Insider 中，我们分享了有关 Compat 2021 和 Interop 2022 计划的一些最新动态。浏览器供应商和生态系统参与者一直在合作，为 Web 带来更多受所有浏览器支持的功能。该计划非常注重 CSS，因为浏览器不兼容是 CSS 开发者面临的最大挑战之一。
虽然这对于大多数人来说可能不是什么新鲜事，但我们很高兴看到我们在各个浏览器中已经取得的进展。
上个月初，我们看到 Safari 发布了 Safari 16.0 Beta 版，其中包含容器查询、子网格和 Flexbox 检查器等令人兴奋的功能。最新版 Firefox 和 Chrome 包含许多令人兴奋的功能和修复，我将在网络平台新功能系列博文中每月介绍稳定版和 Beta 版浏览器中的关键内容。
内部资讯：为 CSS 和界面开发者提供支持
2022 年对于 CSS 功能来说是令人兴奋的一年，我们认为现在是时候带您了解幕后情况了。我与 Web 界面和开发者工具的 DevRel 负责人 Una Kravets 以及专注于 CSS 和 HTML API 的 Web 界面产品经理 Nicole Sullivan 坐下来聊了聊 Chrome 在支持界面开发者方面的历程。
我们先从你们两位开始。请向我们详细介绍一下您自己。
Nicole：我是 Chrome 网页界面的产品经理。我主要关注新的 CSS 和 HTML API，以及构建界面的开发者和设计师。这是一个令人兴奋的领域，即将推出一些非常重要的 API，例如容器查询、范围和（希望！）垂直韵律。
Una：我负责领导 Web 界面和开发者工具 DevRel 团队。我们专注于为 Web 平台上的界面工程师提供支持，并确保他们拥有取得成功所需的工具。这包括 CSS API 和 HTML 组件，以及用于查看有效更改和反馈的开发者工具功能。
在过去几年中，Chrome 对界面开发者的支持不断加快。您认为我们为什么花了这么长时间才到达这里？最大的挑战是什么？
Una：我们需要做一些工作来证明这项工作的重要性，以及为什么它应该成为优先事项。我们于 2019 年开展了 MDN DNA 调查，结果显示界面是该平台上的主要痛点之一。自那时起，我们一直通过 MDN 和我们自己的内部开发者满意度调查，以数据为指引。所有这些努力的成果是，我们获得了更深层次的领导支持，并能够优先处理界面领域中一些最受开发者欢迎的工程工作，这些工作也是 Compat 2021 和 Interop 2022 等计划的主要重点。
Nicole：除了获得领导层的支持外，我们还必须找到将这些 API 提供给开发者的正确方法。我刚加入 Chrome 时，在一个名为 Layered APIs（简称 LAPIs）的项目中犯了这个错误。LAPIs 旨在为开发者提供开箱即用的组件体验。我仍然认为这是一个值得努力实现的出色结果，但我们犯了很多错误！我们首先重点介绍了 Toast 通知和虚拟列表。Toast 几乎无法实现无障碍功能，而虚拟列表是最难正确实现的组件之一。我们的初衷是好的，但该项目对开发者没有帮助，因此我们终止了该项目。以惨痛的代价学习虽然很困难，但每一个错误都在推动当前正在发生的 CSS 和 HTML 复兴。
我们来详细了解一下 LAPIs。这是怎么回事？
Nicole：对于 LAPIs，我们知道 Web 需要一种插入式组件开发者体验，这种体验更接近于构建原生界面。很明显，重新发明轮子会阻碍开发者的发展。我数不清自己职业生涯中制作了多少个标签页！不过，我们尝试通过随浏览器一起发布 JavaScript 来解决这个问题，但难度非常大。之前没有人在浏览器中发布过 JavaScript，也不清楚它应该如何与浏览器渲染引擎所用的 C++ 代码互动。我们听取了其他浏览器供应商的意见（感谢 Mozilla！），放弃了该方法，因此能够通过 Open UI 找到更好的解决方案。通过深入了解 HTML 和 CSS，我们最终可以获得灵活的声明式解决方案。由于它是声明式的，因此我们可以以 JavaScript 难以实现的方式将无障碍功能融入其中。我非常期待看到这一功能的发展。我们正在努力支持 selectmenu、popup、tooltip、nav、accordion、tabs、carousel 和 toggle，这些都是非常重要的界面设计模式。
因此，我们学到了很多。我知道，这方面还有其他计划，例如 CSS Houdini。什么是讲故事？
Una：是的，CSS Houdini 是我们从社区学到的另一个知识点。Houdini 有许多实用的功能，但许多功能过于底层，无法获得更广泛的采用和支持。我们意识到，实现低级 API 并不一定能减少开发者的摩擦。相反，专注于更高级别的解决方案和需求有助于获得跨浏览器支持，并实现生态系统中必要的着陆点。我们目前正在 https://ishoudinireadyyet.com/ 上跟踪进展情况。
说到跨浏览器支持，Interop 2022 和 Open UI 等计划似乎正在为社区带来显著的积极成果。您从开发者那里听到了哪些反馈？
Una：我们从开发者那里听到的最令人头疼的问题之一是“如何让设计在不同浏览器中保持一致”。我们已与其他浏览器供应商合作，优先开发并实现了一些最受开发者欢迎的功能，从而解决了这个问题。我们收到的社区反馈也大多是积极的。此外，通过一项名为 RenderingNG 的大规模重新架构工作，我们得以更高效地实现其中一些功能。开发者很高兴，他们期待已久的这些功能终于开始开发，并将在多个浏览器中实现。
Nicole：社区中的兴奋感显而易见。您可以在 Twitter 上查看。:)
事实证明，与生态系统合作对于我们在让开发者的工作更轻松方面取得的任何成功都至关重要。我知道您的团队一直在努力。您是否愿意分享一些详细信息？
Nicole：首先，我一直对开发者在 Web 上构建的项目感到惊叹。从最小的库到完整的框架，开发者正在构建令人惊叹的产品。这是一个出色的制作者社区。Chrome 正在采取一系列措施，以便与这些项目建立更紧密的联系。
例如，几年前，我们就开始使用 React 和 Angular 等 JavaScript 框架。以及元框架，例如 Next、Nuxt 和 Gatsby。去年，我们开始对 Sass、Bootstrap 和 Material 等界面工具和框架执行相同的操作。我希望在即将到来的一年里，我们能与 GreenSock 和其他能让开发者生活更轻松的工具展开合作。我刚刚在 Smashing Conference 上听了 GreenSock 的 Cassie Evans 的演讲，这让我对与动画领域的同行合作感到非常兴奋。
那么，我们认为 Web 界面生态系统的最大机遇在哪里？
Una：就重大机遇而言，我觉得我们在可自定义的 Web 体验方面才刚刚起步。容器查询和 CSS 用户偏好设置媒体功能等新 API 正在重新定义开发者对自适应设计的看法。此外，我还很高兴看到协作式设计体验的出现，这让开发者和设计师能够与访问其网站的用户协同工作。
Nicole，您的团队接下来有什么计划？
Nicole：并非所有探索都能转化为可发布的产品，但我目前对很多事情都非常兴奋：
Una 提到了第一件事，即我们正在实现自适应的基于组件的设计。它包含用于设计颜色系统的工具，以便设计人员能够根据用户偏好设置（例如深色模式）做出响应。例如，OKLCH 色彩空间可确保亮度在不同色调之间保持一致。设计师可以从选择颜色过渡到设计颜色之间的关系，而不会得到浑浊的调色板！
我们还在开发一些最受期待的 API，例如容器查询、级联层、父选择器 (:has)、作用域样式和嵌套。开发者需要这些功能，以便构建包含可重用组件的灵活设计系统。
滚动关联的动画是另一个有趣的功能。我非常喜欢 Steve Gardner 的演示。它具有非常流畅的滚动效果，并且在滚动时会触发炫酷的飞机动画。虽然这些功能很有趣，但要正确实现它们可能很棘手，尤其是在考虑到无障碍功能的情况下。因此，我们目前正在针对该功能的无障碍功能进行用户测试。
我个人最期待的是内置的 Web 界面控件。开发者不断重复构建相同的标签页集，我认为浏览器可以提供帮助。在 Open UI 中，我们正在开发 selectmenu、popup、tooltip、tabs、nav、accordion 和 toggle 等组件。我们正在探索如何将无障碍功能融入这些浏览器原语中，以便随着时间的推移，网络能够默认实现无障碍访问。这样一来，开发者就可以专注于更复杂、更细致的问题，而标签页如何切换等基本问题则可以由浏览器提供支持。这可能需要单独发一篇博文，所以我就先说到这里！
最后，我们将继续投资于浏览器之间的互操作性。很高兴能与 WebKit 和 Gecko 的同事合作，为开发者带来一致的体验。我们清楚地听到了开发者的心声，他们希望获得此功能！
如果您还没了解过，Seamless Web 团队的共享元素过渡 API 将改变人们设计网页的方式。所有这些细微的过渡效果不仅可以实现，而且非常简单，让设计师能够将设计置于物理空间中。Jake Archibald 有一个很棒的演示。
如果标准进展顺利，我们甚至可能会在今年研究垂直韵律！我们能够基于 LayoutNG 构建，这解锁了许多功能。
感谢两位。我相信，与我们一样，整个社区都非常期待看到 Web 界面在改进和功能方面焕发新的活力。还有很多内容需要理解，您认为应该从何处开始学习？
Una：我们在 I/O 大会上举办的“Web 平台的新变化”讲座介绍了今年推出的许多功能的亮点。Adam Argyle 还撰写了一篇精彩的文章，介绍了所有新的和即将推出的 CSS 功能。目前，我会持续关注稳定版，并留意流水线中即将推出的其他功能。您精彩的“Web 平台新手入门”系列非常适合用于此目的。订阅 web.dev 简报后，开发者还会在收件箱中收到这些内容。对于希望参与并帮助完成所有这些工作的开发者来说，加入 Open UI 是支持这项工作的最佳方式之一。
即将推出的重要更新
我们将继续沿用传统做法，提前告知您即将发生的一项变更，以便您在打造网络体验时注意这一点。
将 Cookie 的最长有效期限限制为 400 天
- 更新：如果设置 Cookie 时带有明确的
Expires/Max-Age属性，该属性的值现在将限制为不超过未来 400 天。之前，没有此限制，Cookie 的过期时间可能在数千年之后。此限制旨在在常见使用模式与尊重用户隐私之间取得平衡。任何访问频率高于每 400 天一次的网站都可以刷新 Cookie，以确保服务连续性，用户可以放心，Cookie 不会在其浏览器中停留数千年而无人使用。 - 预计时间表：在 Chrome 104 中提供（稳定版于 2022 年 8 月 2 日发布）。
- 开发者行动号召：开发者可能需要比以往更频繁地主动刷新 Cookie，以便用户访问其网站。否则，用户可能会在 Cookie 最初设置 400 天后退出账号。
希望您喜欢本期 Chrome Dev Insider。如果您错过了第一期，请点击此处查看第一期。我们期待在下个季度为您带来更多精彩内容。
在此之前，欢迎您告诉我们对本期 Chrome Dev Insider 的看法，以及我们如何才能做得更好。
您认为本期《Chrome 开发者内幕》怎么样？分享您的反馈。