欢迎阅读《Chrome Dev Insider》第二版，我们将在这里分享 Chrome 最新和令人兴奋的方面动态。本期最新发布的内幕消息旨在介绍我们是如何开展工作的，并为您简要介绍您应注意的一些最重要的更新。
我是 Chrome 开发者关系团队的 web.dev 和 developer.chrome.com 内容主管 Rachel Andrew。我从事网络工作已超过 20 年，专注于开放式网络标准和 CSS，是 CSS 工作组的成员。
两个月前，我们结束了 Google I/O 大会，在大会上分享了我们如何支持开发者打造更快、更强大的网络，同时保障用户信息的安全性和私密性。
该团队做了大量的工作来支持网络上的更多 CSS 和界面功能，这也是让社区受到关注的一大亮点（我们也很高兴。在本期 Chrome Dev Insider 中，我们将带您了解这项工作的幕后工作，我们如何努力为 CSS 和 UI 开发者提供支持，以及未来的发展方向。正因如此，我很高兴能主持这一期的 Insider。
资讯
在首期 Chrome Dev Insider 中，我们分享了有关 Compat 2021 和 Interop 2022 计划的一些动态。借助该计划，浏览器供应商和生态系统参与者携手合作，为网络开发了所有浏览器都支持的更多功能。该计划重点关注 CSS，因为浏览器不兼容是 CSS 开发者面临的最大挑战之一。
虽然对大多数人来说这可能不是新闻，但看到我们在浏览器上取得的进展令人兴奋。
上个月早些时候，Safari 宣布推出基于 Safari 16.0 测试版的导视广告版本，其中包括容器查询、subgrid 和 flexbox 检查器等激动人心的功能。Firefox 和 Chrome 的近期版本包含许多激动人心的功能和修复程序。我每个月都会在网络平台新发布系列博文中介绍稳定版和测试版浏览器中的一些重要内容。
内部消息：支持 CSS 和界面开发者
2022 年可谓令人振奋的 CSS 功能一年，我们认为现在是带您了解相关幕后故事的大好时机。我与 Web UI 和开发工具开发主管 Una Kravets 和我们的 Web 界面产品经理 Nicole Sullivan 坐在一起，重点介绍了 Chrome 为界面开发者提供支持的历程。
让我们从双方开始吧。能多介绍一下您自己吗？
Nicole：我是 Chrome 网页界面的产品经理。我主要专注于新的 CSS 和 HTML API，以及构建界面的开发者和设计师。这是一个激动人心的领域，我们将推出一些非常重要的 API，如容器查询、作用域以及（希望如此！）垂直节奏。
Una：我领导 Web 界面和开发者工具开发团队。我们专注于为网络平台上的界面工程师提供支持，并确保他们拥有取得成功所需的工具。这包括 CSS API 和 HTML 组件以及开发者工具功能，用于查看有效的更改和反馈。
在过去几年中，Chrome 对界面开发者的支持速度加快。你觉得怎么花这么长时间才到这里？客户面临的最大挑战是什么？
Una：我们需要做一些工作，以证明这项工作有多重要，以及为什么应该优先开展这项工作。我们从 2019 年的 MDN DNA 调查开始，调查将界面确定为平台上的一些主要痛点。从那时起，我们继续以数据为指导，完成 MDN 和我们自己的内部开发者满意度调查。这一切的结果是，我们能够获得更深入的领导层认可，并能够优先围绕界面领域开发者最迫切的一些功能开展工程工作，而这些功能也成为 Compat 2021 和 Interop 2022 等计划的重点重点。
Nicole：除了获得领导层的认可，我们还要找到将这些 API 提供给开发者的正确方式。刚加入 Chrome 时，我在一个名为 Layered APIs（简称 LAPI）的项目中搞乱了。旨在为开发者提供普适性组件体验的 LAPI。我仍然认为这是一个不错的结果，但我们犯了很多错误！我们首先重点介绍了消息框通知和虚拟列表。消息框几乎不可能访问，而虚拟列表是最难正确使用的组件之一。我们的本意不错，但对开发者没有帮助，因此我们停止了这个项目。虽然难以掌握，但每一个错误都在推动 CSS 和 HTML 的复兴。
我们来深入探讨一下 LAPI。当时发生了什么？
Nicole：对于 LAPI，我们知道 Web 需要一种更接近构建原生界面的普适性组件开发者体验。显而易见，不断重复创新的做法阻碍了开发者的发展。我的职业生涯建立了多少标签页，真是数不胜数！尽管如此，我们试图通过为浏览器提供 JavaScript 来解决这个问题，但这非常困难。以前，没有人在浏览器中推出 JavaScript，并且不清楚它应该如何与支持浏览器渲染引擎的 C++ 代码进行交互。我们听取了其他浏览器供应商的意见（谢谢 Mozilla！），但后来就不再采用这种做法，因此我们找到了使用开放式界面改进的功能。通过使用 HTML 和 CSS，我们最终得到了灵活的声明式解决方案。由于它是声明性的，因此我们能够以使用 JavaScript 不那么容易的方式纳入无障碍功能。我对未来发展方向感到非常兴奋。我们正在努力支持 selectmenu、弹出式窗口、tooltip、nav、手风琴、标签页、轮播和切换开关，这些是真正基本的界面设计模式。
我们学到了很多。我知道这个领域还有其他计划，例如 CSS Houdini。故事情节是什么？
Una：没错，CSS Houdini 也是我们从社区中吸取的另一个教训。Houdini 的功能有很多，但其中很多功能太低，无法得到更广泛的采用和支持。我们发现，实现低级别 API 未必能为开发者减少麻烦。相反，专注于更高级的解决方案和需求，有助于获得跨浏览器的支持和必要的着陆，从而推动生态系统的发展。我们目前正通过 https://ishoudinireadyyet.com/ 跟踪进度。
说到跨浏览器支持， Interop 2022 和开放式界面等举措似乎为社区带来了显著的积极成果。开发者都有哪些反馈？
Una：据开发者反馈，最大的痛点之一是“让设计在各种浏览器中以相同方式运行”。为了解决此问题，我们与其他浏览器供应商合作，确定一些开发者呼声最高的功能并优先推出这些功能。我们收到的用户社区的反馈无疑是极为积极的。此外，通过一个名为 RenderingNG 进行大规模的重新架构调整，可以大幅提升其中一些功能的性能。开发者们期待着他们多年来一直期待的这些广受期待的功能终于得以开发并实现跨浏览器。
Nicole：社区中的热情是显而易见的。您可以在 Twitter 上查看。:)
事实证明，与生态系统合作对我们在打造开发者体验方面取得的成功至关重要让生活更轻松我知道您的团队在这方面做了大量工作。想要分享一些详细信息？
Nicole：首先，我一直对开发者在网络上构建的项目感到惊叹。从最小的库到全面的框架，开发者都在构建出色的产品。这是一个很棒的制作者社区。Chrome 正在采取一系列措施，以便与这些项目建立更紧密的联系。
例如，几年前，我们开始使用 React 和 Angular 等 JavaScript 框架。还有元框架，例如 Next、Nuxt 和 Gatsby。去年，我们开始利用 Sass、Bootstrap 和 Material 等界面工具和框架来执行同样的操作。我希望来年能与 GreenSock 和其他工具合作，让生活更轻松我刚刚看到来自 GreenSock 的 Cassie Evans 在 Smashing Conference 上发表演讲，我对与动画行业的同事们的合作感到非常兴奋。
那么，我们在哪里看到了 Web 界面生态系统的最大机会呢？
Una：就重大机会而言，我认为可自定义的 Web 体验只是冰山一角。容器查询和 CSS 用户偏好设置媒体功能等新 API 正在重新定义开发者查看自适应设计的方式。此外，协作式设计体验使开发者和设计人员能够与访问其网站的用户协同工作，这也让我感到非常兴奋。
Nicole，您团队的下一步计划是什么？
Nicole：并不是所有探索都变成了可运输的东西，但是我现在非常开心的很多事情：
首先，我们要实现基于组件的自适应设计。它包含用于设计颜色系统的工具，以便设计师可以响应用户偏好设置（例如深色模式）。例如，OKLCH 颜色空间可在不同色调之间保持亮度一致。设计师可以从选择颜色到设计颜色之间的关系，最终得到的都是看起来模糊不清的调色板！
我们还致力于开发一些呼声最高的 API，例如容器查询、级联层、父级选择器 (:has)、限定了范围的样式和嵌套。开发者需要这些组件，才能构建充满可重用组件的灵活设计系统。
滚动链接的动画是另一个有趣的方面。我非常喜欢 Steve Gardner 的演示。他的滚动操作流畅流畅，滚动时会触发炫酷的飞机动画。虽然这些都很有趣，但可能很难正确掌握，尤其是要考虑到无障碍性。因此，我们正在针对该功能运行无障碍功能的用户测试。
我个人最感兴趣的是内置的网页界面控件。开发者会反复构建相同的 Tabset，我认为浏览器可以帮助您。在打开界面部分，我们正在处理一些组件，例如选择菜单、弹出式窗口、提示、标签页、导航、手风琴式折叠和切换开关。我们正在探索将无障碍功能内置到这些浏览器原语中，以便随着时间的推移，可以默认访问网络。这样，开发者就可以集中精力解决更为复杂和微妙的问题，而浏览器也可以支持一些基本问题，如标签页标签页的操作方法。这可能需要一个单独的帖子，所以现在我就到此为止了！
最后，我们将继续投资打造不同浏览器之间的互操作性。我们很高兴与 WebKit 和 Gecko 的员工合作，共同为开发者提供一致的体验。我们清楚地听到开发者们非常希望这样！
哦，如果您还没有体验过，Seamless Web 团队的 Shared Element Transitions API 将改变人们进行 Web 设计的方式。这些微妙的转场，让设计师能够在物理空间中确定其设计方向，不仅可能实现，而且非常容易。Jake Archibald 提供了精彩的演示。
如果标准进展顺利，我们今年甚至可能会关注竖屏节奏！我们能够在 LayoutNG 进行构建，这解锁了许多功能。
感谢两位的分享。我相信整个社区（和我们一样）都非常期待看到网络界面世界不断更新改进和功能。他们还有很多事情要探究，那么您认为应该从哪里开始他们的旅程呢？
Una：I/O 大会上的 Web 平台新变化专题演讲介绍了今年推出的诸多功能的亮点。Adam Argyle 还写了一篇精彩的文章，介绍了所有新推出和即将推出的 CSS 着陆页。我现在会一直专注于稳定版本，只是了解即将发布的其他工作。不妨再看一看精彩的“网络平台新手”系列，该系列课程非常适合后续学习。订阅 web.dev 简报也会为开发者提供收件箱。对于希望参与这一切并提供帮助的开发者，加入 Open UI 是支持这些工作的最佳方式之一。
即将发布的重要更新
我们的一贯传统旨在提醒您注意即将发生的变化，您在打造网络体验时应注意这一点。
将 Cookie 的最长存在时间限制为 400 天
- 更新：现在，使用显式
Expires/Max-Age属性设置 Cookie 时，其上限在未来 400 天内。以前，网站没有设置限制，Cookie 可能会在几千年后过期。此限制的目标是在常见的使用模式和尊重用户隐私之间取得平衡。任何访问频率高于每 400 天一次的网站都可以刷新 Cookie，以确保服务的连续性，用户可以放心，Cookie 不会在其浏览器上保留长达千年之久。 - 预计时间表：在 Chrome 104 中推出（将于 2022 年 8 月 2 日稳定）。
- 开发者 CTA：当用户访问其网站时，开发者可能需要比以前更频繁地主动刷新 Cookie。否则，用户可能会在 Cookie 初次设置 400 天后退出登录。
希望您喜欢本期 Chrome Dev Insider。如果你错过了，欢迎收听第一个。我们期待在下一季度为大家提供更多帮助。
在此之前，请告诉我们您对本版 Chrome Dev Insider 的看法，以及我们如何改进它。
您对这一期《Chrome Dev Insider》有何看法？欢迎分享反馈。