今天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 容器查询,为自适应布局方案提供了一种新的思路。
可是目前还处于提案阶段, 感兴趣的能够保持关注。
好了,本文的内容就这么多,谢谢。
最后,若是以为内容有帮助, 能够关注下个人公众号,掌握最新动态,一块儿学习!