欢迎阅读第 2 期 Chrome 开发者内幕。我们将在其中分享 Chrome 社区和 Chrome 的最新动态。这是“内部人员故事”系列的新一集，介绍了我们是如何开展工作的，并简要介绍了一些您应该关注的重要更新。
我是 Chrome 开发者关系团队的 web.dev 和 developer.chrome.com 内容主管 Rachel Andrew。我从事 Web 工作已经 20 多年，专注于开放 Web 标准和 CSS，是 CSS 工作组的成员。
两个月前，我们举办了 Google I/O 大会，并在其中分享了一些最重要的动态，介绍了我们如何帮助开发者让 Web 变得更快速、更强大，同时确保用户信息的安全和隐私。
其中一个亮点（我们很高兴社区注意到了！）是该团队为支持 Web 上更多 CSS 和界面功能所做的大量工作。在本期 Chrome Dev Insider 中，我们将带您深入幕后，了解这项工作的幕后团队、我们如何为 CSS 和界面开发者提供支持，以及未来的发展方向。因此，我非常高兴能主持本期“Google 内部人员动态”。
新闻报道
在首个 Chrome Dev Insider 中，我们分享了有关 Compat 2021 和 Interop 2022 计划的一些最新动态。浏览器供应商和生态系统参与者一直在合作，为 Web 带来更多受所有浏览器支持的功能。该计划重点关注 CSS，因为浏览器不兼容是 CSS 开发者面临的最大挑战之一。
这对大多数人来说可能并不新鲜，但我们很高兴看到自己在各个浏览器上的进展。
上个月初，Safari 宣布发布了 Safari 16.0 Beta 版，其中包含容器查询、子网格和弹性盒网格检查器等令人兴奋的功能。近期发布的 Firefox 和 Chrome 版本包含许多令人兴奋的功能和修复程序。我会在刚接触 Web 平台系列文章中，每月介绍稳定版和 Beta 版浏览器中的关键内容。
内幕消息：为 CSS 和界面开发者提供支持
2022 年将是 CSS 功能令人兴奋的一年，因此我们认为现在是时候带您了解幕后工作了。我与 Web 界面和开发者工具的 DevRel 主管 Una Kravets 以及专注于 CSS 和 HTML API 的 Web 界面产品经理 Nicole Sullivan 进行了对话，探讨了 Chrome 为界面开发者提供支持的历程。
我们先从你们俩开始。能否请您详细介绍一下自己？
Nicole：我是 Chrome 网页界面的产品经理。我专注于新的 CSS 和 HTML API，以及构建界面的开发者和设计师。这是一个令人兴奋的领域，即将推出一些非常重要的 API，例如容器查询、镜重和（希望）垂直节奏。
Una：我负责 Web 界面和开发者工具开发者关系团队。我们专注于为 Web 平台上的界面工程师提供支持，确保他们拥有取得成功所需的工具。其中包括 CSS API 和 HTML 组件，以及用于查看正在进行的更改和反馈的 DevTools 功能。
Chrome 在过去几年里对界面开发者的支持力度不断加强。您认为为什么花了这么长时间才收到回复？最大的挑战是什么？
Una：我们需要做一些工作来证明这项工作的重要性，以及为什么应将其列为优先事项。我们首先参考了 2019 年的 MDN DNA 调查问卷，该调查问卷指出界面是该平台的一大痛点。从那时起，我们一直在通过 MDN 和我们自己的内部开发者满意度调查，以数据为依据来指导我们的工作。所有这些工作最终取得了成效，我们不仅获得了高层的更大支持，还能够优先围绕界面领域最受开发者欢迎的一些功能开展工程工作，这些功能也是 Compat 2021 和 Interop 2022 等计划的重点关注对象。
Nicole：除了获得高层支持外，我们还必须找到合适的方式将这些 API 提供给开发者。刚加入 Chrome 时，我在一个名为分层 API（简称 LAPI）的项目中就犯了这个错误。LAPI 旨在为开发者提供插入式组件体验。我仍然认为这是我们可以追求的理想结果，但我们犯了很多错误！我们首先重点介绍了Toast 通知和虚拟列表。几乎无法让 Toast 实现无障碍功能，而虚拟列表是最难正确实现的组件之一。我们的初衷是好的，但该项目并未给开发者带来帮助，因此我们已将其弃用。通过艰难的方式学习很难，但每一次错误都会推动 CSS 和 HTML 的复兴。
我们来详细了解一下 LAPI。发生了什么情况？
Nicole：对于 LAPI，我们知道 Web 需要一种更接近于构建原生界面的插入式组件开发者体验。显然，重新发明轮子会阻碍开发者。我职业生涯中构建的标签页数量不计其数！尽管如此，我们还是尝试通过将 JavaScript 与浏览器一起分发来解决此问题，但这非常困难。之前还没有人发布过浏览器中的 JavaScript，因此我们不清楚它应该如何与为浏览器的渲染引擎提供支持的 C++ 代码进行交互。我们听取了其他浏览器供应商的意见（感谢 Mozilla！），放弃了这种方法，因此我们能够通过开放式界面找到更好的解决方案。通过使用 HTML 和 CSS，我们最终获得了灵活的声明式解决方案。由于它是声明式的，因此我们可以以 JavaScript 无法轻松实现的方式内置无障碍功能。我非常期待后续的发展。我们正在努力支持 selectmenu、popup、tooltip、nav、accordion、tab、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、tab、nav、accordion 和 toggle 等组件。我们正在探索将无障碍功能融入这些浏览器基元会有什么效果，以便 Web 最终能默认支持无障碍功能。这样一来，开发者就可以专注于更复杂、更细致的问题，而浏览器可以支持标签页如何标签页等基本操作。这可能需要单独发帖，因此我暂时就说到这里吧！
最后，我们将继续投资于浏览器之间的互操作性。很高兴能与 WebKit 和 Gecko 团队合作，为开发者提供一致的体验。我们清楚地听到了开发者对此的需求！
哦，如果您还没有查看过，请了解一下顺畅 Web 团队的 Shared Element Transitions API，它将改变人们设计 Web 应用的方式。所有这些细微的过渡效果不仅可行，而且还很容易实现，让设计师能够在物理空间中调整其设计的方向。Jake Archibald 提供了一个绝佳的演示。
如果标准顺利实施，我们今年甚至可能会考虑竖屏节奏！我们能够在 LayoutNG 的基础上进行构建，从而解锁许多功能。
谢谢你们。我相信，整个社区都和我们一样，对网页界面领域不断推出的改进和功能感到兴奋。我们还有很多知识需要学习，您认为从哪里入手比较好？
Una：我们在 I/O 大会上举办的 Web 平台的新变化专题演讲介绍了今年推出的许多功能的亮点。Adam Argyle 还撰写了一篇精彩的文章，介绍了所有新推出和即将推出的 CSS 着陆页。目前，我会继续专注于稳定版，并留意后续的其他工作。您可以参阅出色的 Web 平台新手入门系列文章，了解相关信息。订阅 web.dev 简报后，开发者也会在收件箱中收到这些内容。对于希望参与其中并协助完成所有这些工作的开发者，加入 Open UI 团队是支持这项工作的最佳方式之一。
即将推出的重要更新
一如既往，我们会提前告知您即将发生的变更，以便您在构建 Web 体验时留意。
将 Cookie 的 max-age 限制为 400 天
- 更新：今后，使用显式
Expires/Max-Age属性设置 Cookie 时，该值的期限上限将不超过 400 天。以前，没有任何限制，Cookie 的失效时间可以设为数千年后。此限制旨在在常见使用模式与尊重用户隐私之间取得平衡。如果用户每 400 天内访问某个网站的频率超过一次，该网站就可以刷新 Cookie，以确保服务的连续性。用户可以放心，Cookie 不会在浏览器中保留数千年而无人使用。 - 预计时间安排：Chrome 104 中提供（2022 年 8 月 2 日发布稳定版）。
- 开发者号召性用语：在用户访问其网站时，开发者可能需要比以前更频繁地主动刷新 Cookie。否则，用户可能会在最初设置 Cookie 后的 400 天后被退出账号。
希望您喜欢阅读本期 Chrome 开发者内幕。如果您错过了第一期，请点击此处查看。我们期待在下一季度为您带来更多精彩内容。
在此之前，欢迎告诉我们您对本期 Chrome Dev Insider 的看法，以及我们可以做些什么来改进。
您对本期《Chrome 开发者内参》有何看法？分享您的反馈。