Chrome 120 有哪些值得关注的更新？

Chrome 120 已于近日发布了稳定版本，今天和大家来聊聊这个版本值得关注的一些更新。

Close Watcher API

模态或弹窗组件的一个重要特性是他们很容易被关闭，而且有一致的机制来执行这个操作。这些机制一般被称为关闭请求，它们通常在桌面平台上通过 ESC 键，或者在 Android 平台则通过后退手势或按钮来实现。

当前 Web 开发者对于自己的组件没有很好的方式来处理这种关闭请求，尤其是在 Android 设备上，这种问题相当明显，因为为后退手势提供简单的关闭行为相当复杂。

Chrome 120 带来了这个问题的解决方案 —— CloseWatcher，这是一个新的 API，可以用于直接监听和响应关闭请求。它还升级了 <dialog> 和 popover=""，让他们能使用新的 Close Watcher API ，从而能响应 Android 的返回按钮。

开发者首先需要创建一个新的 CloseWatcher 实例。当用户发送一个关闭请求，比如按下 Esc 键或者安卓的返回键时，CloseWatcher 会触发一个 onclose 事件。开发者可以通过监听这个事件，来处理用户的关闭请求。

API 提供了一种方法，叫做 watcher.destroy()，用于销毁不再需要的观察器。这对于防止将来的事件出现在这个观察器上，以及释放 "free CloseWatcher slot "非常有用。

此外，API还有一种进阶用法，允许开发者请求关闭确认。这在一些情况下非常有用，比如，如果一个对话框包含了未保存的数据，用户可能不小心关闭了它，并且可能会丢失数据。在这种情况下，开发者可以使用 API 的 oncancel 事件，来阻止默认的关闭行为，并弹出一个确认对话框，让用户确认是否真的要关闭。要注意的是，在 Android 平台上，为防止滥用，oncancel 事件只有在接收到用户激活的情况下才会触发。如果用户连续两次发送关闭请求，第二次的请求一定会过去，销毁 CloseWatcher。

下面是一个基本的使用示例：

// 首先，你需要创建一个新的CloseWatcher实例
const watcher = new CloseWatcher();

// 然后，你可以给CloseWatcher实例添加一个onclose事件监听器
watcher.onclose = () => {
  console.log('用户已经发起了关闭请求，例如按Esc键或者安卓的返回键');
};

// 当你不再需要CloseWatcher时，你可以销毁它
watcher.destroy();

// 如果你想在用户试图关闭某个对话框时弹出一个确认对话框，你就需要使用oncancel事件
const confirmWatcher = new CloseWatcher();
confirmWatcher.oncancel = (event) => {
  // 阻止默认的关闭行为
  event.preventDefault();
  
  // 弹出确认对话框
  const userConfirmed = confirm('你有未保存的数据，是否真的要关闭？');
  if(userConfirmed) {
    // 如果用户确认要关闭，你可以手动触发一个关闭事件
    confirmWatcher.destroy();
  }
};

details 新增 name 属性

<details> 元素新增了一个 name属性，可以为我们轻松的创建手风琴效果（accordion pattern）。

手风琴效果是 GUI 设计中常见的一种设计元素，通常用于在有限的空间内展示大量内容。当我们点击某个部分时，相关的内容就会展开，而其他部分则会保持收起状态。

<details> 元素的 name 属性正是用来实现这样的效果。它支持将多个 <details> 元素通过相同的 name 属性值串联在一起形成一个组，使得在一个组内最多只能有一个元素处于打开的状态。换句话说，在一个组内，一旦一个 <details> 元素被打开，其他所有 <details> 元素都会被关闭。

<details name="product">
  <summary>code秘密花园A</summary>
  这是我们的产品A，它具有高效的性能和优秀的设计。
</details>
<details name="product">
  <summary>code秘密花园B</summary>
  这是我们的产品B，它具有强大的功能和一流的质量。
</details>
<details name="product">
  <summary>code秘密花园C</summary>
  这是我们的产品C，它以其用户友好的界面和高度的可便捷性获得赞叹。
</details>
<details name="product">
  <summary>code秘密花园D</summary>
  这是我们的产品D，它符合现代审美并且易于上手。
</details>

Permissions Policy 支持了 Reporting API

Permissions Policy，前称为 Feature Policy，是一种允许开发者控制页面、其内部的 iframes 和子资源可访问的浏览器功能的策略。开发者可以通过声明一系列政策来指示浏览器强制执行哪些功能，这些政策将应用于响应头部 origin 列表中提供的源。该列表可以包含同源或跨源，允许开发者控制第一方和第三方对浏览器功能的访问。

举个例子，假设你是一个网站的拥有者，希望控制你的网站和第三方代码如何使用浏览器功能。例如，只允许你的网站和你信任的网站使用地理位置功能，而不是广告 iframes 。在这种情况下，可以使用如下 Header：

Permissions-Policy: geolocation=(self "https://trusted-site.example")

然后在信任的网站的 iframe 标签中明确设置 allow 属性。例如：

<iframe src="https://trusted-site.example" allow="geolocation">

在这个例子中，头部 origin 列表只允许你的网站(self)和 trusted-site.example 使用地理位置功能，而 ad.example 则不允许使用地理位置功能。

现在它支持了了 Reporting API，你可以在浏览器遇到政策违反时接收到报告。

下面是一个结合 Reporting API 进行上报的案例：

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;

关于 Reporting API 我之前专门写过介绍它的文章，详细请看：使用浏览器的 Reporting API 上报站点错误

更宽松的 CSS 嵌套语法

Chrome 在今年早些时候推出了 CSS 嵌套功能，并且目前已经被各大浏览器采纳。然而，这个特性在最初发布时带有一项严格可能令人意外的语法要求：无法直接嵌套单一元素标签名称。在这个版本中，该限制已经被去除，以下的 CSS 嵌套现在都是合法的：

.card {  
    h1 {    
        /* this is now valid! */  
    }
}

这与以下代码等价：

.card {  
    & h1 {    
        /* this is now valid! */  
    }
}

在嵌套有序列表、无序列表或定义列表时，这个改变显得特别方便：

dl {  
    dt {   
         /* dl dt styles */  
    }  
    dd {    
         /* dl dd styles */  
    }
}

再次提醒三方 Cookie 禁用

距离 Chrome 宣布的三方 Cookie 禁用时间线的第一个节点：2024 Q1 开启 1% 禁用，已经剩下不到一个月的的时间了， 这项禁用是一项可能会影响你网站正常行为的更新，Chrome 因此也在 120 版本再次向开发者发出了提醒，如果你还没有开始确认影响，请尽量看下我这篇文章吧：