今天PM過來問我: 蛋總,有些用戶反饋他們屏幕過小了,須要滑動, 操做不方便。 咱們的系統能不能改爲自適應佈局
啊?css
我頓時虎軀一震:woc, 要把一個迭代了一年多的固定設計的產品,改爲自適應佈局? 真讓人懼怕。chrome
而後我就去查了一些自適應佈局的資料,嘗試找出一種改形成本最小的方案。瀏覽器
過程當中發現了一個比較好玩的東西:CSS 容器查詢
。性能優化
對此,我作了一下簡單的整理和總結,在此分享給你們,但願對你們有所啓發。ide
容器查詢容許開發者根據容器元素的大小
來設置元素的樣式。佈局
它相似於 @media
查詢,不一樣之處在於它根據容器的大小
而不是視口的大小
進行判斷。性能
咱們使用建立響應式設計時,一般使用媒體查詢
根據視口的大小
來更改文檔佈局。學習
可是,許多設計都有一些通用組件,這些組件會根據其容器的可用寬度來更改佈局。測試
這可能並不老是與視口的大小有關
,而是與組件在佈局中的放置位置有關
。優化
例如,如下組件可能顯示在網站佈局的窄
或寬
列中。
若是有空間,它將顯示爲兩列,不然,咱們但願將其堆疊顯示。
上圖中的左右兩個組件,是同一個組件,功能上是徹底同樣的,只是要展現不一樣的佈局。
目前來講, 咱們能夠經過以某種方式識別該組件,好比經過添加一個類
或使用其餘選擇器
來定位元素,該選擇器能夠查看它在文檔結構中的位置。
可是,這並不能徹底實現媒體查詢在整個佈局中的做用。
媒體查詢使咱們可以根據視口的範圍來改變元素的大小。
當咱們添加一個類或目標元素時,咱們決定當對象在側邊欄中時,它必須使用堆疊佈局。
可是,就可用空間而言,極可能是在大屏幕上,側邊欄中的對象將具備足夠的空間來以並排佈局顯示。
容器查詢將解決這種狀況。
除了查看視口的大小,咱們還能夠查看容器的大小,並根據容器中的空間進行佈局調整。
容器查詢, 將成爲css containment
規範的一部分,並向contain
屬性添加新值。
該contain屬性
最初是爲了性能優化
而設計的。
它爲Web開發人員提供了一種方法來隔離DOM的各個部分,並向瀏覽器聲明這些部分與文檔的其他部分無關。
使用contain: size;
表示瀏覽器在兩個維度上都知道該區域的大小。
知道它有多大的容器,正是咱們進行容器查詢所須要的。
可是,一般咱們並不常常知道這兩個維度有多大。
當咱們使用媒體查詢時,大多數時候咱們都會指定可用的寬度(或內聯大小)。
咱們將列定義爲: 該維度中,空間的百分比
或分數
。
所以,容器查詢僅容許經過在一維
中指示大小來擴展包含屬性,這被描述爲單軸遏制
。
如下CSS將建立一個僅在嵌入式軸上包含容器的容器,內容能夠增加到在塊軸上所需的大小:
.sidebar { contain: layout inline-size; }
聲明contain
屬性,而且把layout
和size
的值疊加, 瀏覽器便會在該元素上建立一個containment
上下文。
聲明瞭這個屬性,就意味着瀏覽器知道: 我之後可能要查詢此容器。
而後,能夠編寫一個查詢來查找此包含上下文而不是視口大小,以便爲組件制定佈局決策。
使用建立容器查@container
。
這將查詢最近的包含上下文。
爲了使卡僅在邊欄寬於700px時才顯示爲兩列,咱們使用如下CSS:
@container (min-width: 700px) { .card { display: grid; grid-template-columns: 2fr 1fr; } }
若是佈局的其餘區域也是containment,那麼咱們能夠將組件放到那些區域中,它將自動響應相關的容器。這使得咱們能夠在模式庫中建立的各類組件真正可重用,而無需知道它們所處的上下文。
其實還有不少事情能夠說,上文介紹的只是一些基本概念。
另外,上文顯示的基本功能都已經能夠在Chrome Canary
中進行測試。
下載Canary
,而後轉到chrome://flags
,搜索Container Queries
並啓用該標誌。
本文演示
的 demo 的在線連接:
https://codepen.io/rachelandr...
以及容器查詢 demo 的大集合
:
https://codepen.io/collection...
目前尚未瀏覽器支持。
https://bugs.chromium.org/p/c...
Tracking bug:
https://bugs.chromium.org/p/c...
Chrome瀏覽器中提供功能後,此處列出的值不保證是最新的。
CSS 容器查詢,爲自適應佈局方案提供了一種新的思路。
可是目前還處於提案階段, 感興趣的能夠保持關注。
好了,本文的內容就這麼多,謝謝。
最後,若是以爲內容有幫助, 能夠關注下個人公衆號,掌握最新動態,一塊兒學習!