别忘了容器查询

容器查询一直是 CSS 改进要求清单的首位。普遍观点是，如果我们有了容器查询，就不会再写那么多基于页面大小的全局媒体查询。这是因为我们实际上想要控制一个更局部的容器，而现在我们之所以使用媒体查询来实现这一点，只是因为它是 CSS 中最好的工具。我绝对相信这一点。

偶尔会有人说：“你们开发者以为需要容器查询，其实并不需要。” 我不喜欢这种说法。我认为，如果容器查询可用，我们会用它做很多好事，至少可以写出更干净、可移植、易于理解的代码。如今，大家似乎都认为用组件构建 UI 是最佳实践，这使得容器查询的必要性更加明显。

今天，我们有一些现代 JavaScript 概念可以帮助我们使用容器查询，但这并不意味着这项技术就应该停留在 JavaScript 中。它更适合放在 CSS 中。

这是我在 2019 年底关于这个主题的一些想法。

• Philip Walton 的 “响应式组件：解决容器查询问题的方案” 文章很好地介绍了如何使用 JavaScript 的 ResizeObserver 来解决今天的问题。它的性能很好，而且可以在任何地方工作。 演示网站 是目前最好的演示，因为它突出了响应式组件的必要性（尽管还有其他 已记录的使用案例）。Philip 也说过，纯 CSS 解决方案会更理想。
• CSS 嵌套大约一年前获得了 一阵热潮。讨论似乎表明嵌套是可行的。我支持这一点，因为我一直 喜欢合理的 Sass 嵌套。这让我不禁想，容器查询的语法是否可以利用类似的东西。也许嵌套查询是限定在父选择器范围内的？或者，你可以像当前规范中使用后代选择器那样，在媒体语句前加上一个与号？
• 其他建议的语法通常涉及某种冒号的使用，例如 .container:media(max-width: 400px) { }。我也喜欢这个。单冒号选择器（伪选择器）在哲学上来说是“在这些条件下选择元素”——比如 :hover、:nth-child 等等——所以媒体范围是有道理的。
• 我认为语法不是这个特性的最大障碍，而是实现方式的性能。我上次了解到的情况是，问题甚至不在于性能，而在于它会影响浏览器的整个渲染流程。这似乎是一个巨大的障碍。但我还是不想放弃它。网络上正在发生很多创新，即使今天还不知道如何实现它，并不意味着明天就没有人能找到一条切实可行的路径。