让我们不要忘记容器查询

CSS 容器查询一直是开发者们强烈要求改进的特性之一。普遍观点认为，如果有了容器查询，我们就不需要编写那么多基于页面大小的全局媒体查询。因为我们真正想要控制的是更局部的容器，而现在只能使用媒体查询来实现，仅仅是因为它是 CSS 中最好的工具。我完全认同这一点。

但也有一种时不时出现的观点：“开发者们觉得需要容器查询，但实际上并不需要。” 我并不赞同这种说法。如果容器查询可用，我们显然可以用它做很多有益的事情，其中最重要的是编写更简洁、更易移植、更易理解的代码。如今，构建基于组件的 UI 似乎已成为共识，这使得容器查询的需求更加明显。

目前有一些现代 JavaScript 方法可以帮助我们在今天使用容器查询——但这并不意味着这项技术需要停留在 JavaScript 领域。它在 CSS 中更有意义。

以下是 2019 年年末我对这个主题的一些想法：

• Philip Walton 的“响应式组件：解决容器查询问题的方案”很好地展示了如何使用 JavaScript 的 ResizeObserver 来解决当前的问题。它的性能很好，并且可以在任何地方工作。演示网站是最好的一个，因为它突出了响应式组件的需求（尽管还有其他已记录的用例）。Philip 甚至表示纯 CSS 解决方案会更理想。
• 大约一年前，CSS 嵌套引起了一阵热潮。讨论似乎表明嵌套是可行的。作为长期以来对合理 Sass 嵌套的拥护者，我赞成这一点。这让我不禁想到，容器查询的语法是否可以利用类似的东西。也许嵌套查询的范围仅限于父选择器？或者你用一个＆符号作为前缀来表示媒体语句，就像当前规范对后代选择器所做的那样？
• 其他提出的语法通常涉及某种冒号的使用，例如 .container:media(max-width: 400px) { }。我也喜欢这个。单冒号选择器（伪选择器）在哲学上是“在这些条件下选择元素”——例如 :hover、:nth-child 等——因此媒体范围是有意义的。
• 我不认为语法是这项功能最大的障碍；而是它的实现性能。据我最后了解，它甚至与其说是性能问题，不如说是它扰乱了浏览器的工作方式的整个渲染流程。这似乎是一个巨大的障碍。但我仍然不想忘记它。网络上正在发生许多创新，仅仅因为今天尚不清楚如何实现它，并不意味着明天就没有人会找到一条切实可行的前进道路。

以上是让我们不要忘记容器查询的详细内容。更多信息请关注PHP中文网其他相关文章！