讓我們不要忘記容器查詢

CSS 容器查詢一直是開發者們強烈要求改進的特性之一。普遍觀點認為，如果有了容器查詢，我們就不需要編寫那麼多基於頁面大小的全局媒體查詢。因為我們真正想要控制的是更局部的容器，而現在只能使用媒體查詢來實現，僅僅是因為它是CSS 中最好的工具。我完全認同這一點。

但也有一種時不時出現的觀點：“開發者們覺得需要容器查詢，但實際上並不需要。” 我並不贊同這種說法。如果容器查詢可用，我們顯然可以用它做很多有益的事情，其中最重要的是編寫更簡潔、更易移植、更易理解的代碼。如今，構建基於組件的UI 似乎已成為共識，這使得容器查詢的需求更加明顯。

目前有一些現代JavaScript 方法可以幫助我們在今天使用容器查詢——但這並不意味著這項技術需要停留在JavaScript 領域。它在CSS 中更有意義。

以下是2019 年年末我對這個主題的一些想法：

• Philip Walton 的“響應式組件：解決容器查詢問題的方案”很好地展示瞭如何使用JavaScript 的ResizeObserver 來解決當前的問題。它的性能很好，並且可以在任何地方工作。演示網站是最好的一個，因為它突出了響應式組件的需求（儘管還有其他已記錄的用例）。 Philip 甚至表示純CSS 解決方案會更理想。
• 大約一年前，CSS 嵌套引起了一陣熱潮。討論似乎表明嵌套是可行的。作為長期以來對合理Sass 嵌套的擁護者，我贊成這一點。這讓我不禁想到，容器查詢的語法是否可以利用類似的東西。也許嵌套查詢的範圍僅限於父選擇器？或者你用一個＆符號作為前綴來表示媒體語句，就像當前規範對後代選擇器所做的那樣？
• 其他提出的語法通常涉及某種冒號的使用，例如.container:media(max-width: 400px) { } 。我也喜歡這個。單冒號選擇器（偽選擇器）在哲學上是“在這些條件下選擇元素”——例如:hover 、 :nth-child等——因此媒體範圍是有意義的。
• 我不認為語法是這項功能最大的障礙；而是它的實現性能。據我最後了解，它甚至與其說是性能問題，不如說是它擾亂了瀏覽器的工作方式的整個渲染流程。這似乎是一個巨大的障礙。但我仍然不想忘記它。網絡上正在發生許多創新，僅僅因為今天尚不清楚如何實現它，並不意味著明天就沒有人會找到一條切實可行的前進道路。

以上是讓我們不要忘記容器查詢的詳細內容。更多資訊請關注PHP中文網其他相關文章！