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