响应式布局发展到今天已经不再只是简单的使页面在手机上和电脑上都可以正常显示了。各种各样的设备层出不穷，比如折叠屏、平板、智能电视以及汽车里的显示屏等等，每个设备都有自己的显示方式。为了应对这样的情况，CSS所提供的布局手段也在不断进化之中。最初是通过媒体查询来进行断点适配，而现在则是容器查询开始被应用起来，“看屏幕”的思路正逐渐向“看组件”的方向转变。
媒体查询就是响应式布局的基础，在@media规则下可以依据视口宽度、高度、方向以及分辨率等不同条件来使用不同的样式。最常用的方式就是设置多个断点，例如768px、1024px和1280px等等，在每个断点区间里改变栅格列数、字体大小或者隐藏一些元素。移动优先的方法一般是先写出小屏幕的样式之后再逐步添加更大的宽度。这样的好处是逻辑清楚而且浏览器兼容性很好，几乎不会遇到不支持媒体查询的情况。
但是媒体查询有一个基本的限制，它只能检测到视口大小的变化，而不能察觉到元素本身所在的容器的大小。例如，在一个卡片组件中，当它被放置在侧边栏的时候宽度为280像素；而当它被放到主要内容区域时，宽度可以达到800像素。如果卡片里面的布局需要随着宽度的改变而进行调整的话，那么媒体查询就无法发挥作用了——它只能告知浏览器“现在的视口是1200像素”，但是不能告诉卡片“你现在所处的容器只有280像素”。以前解决这个问题一般是用JavaScript来监听元素尺寸或者为不同的场景创建不同的类名，这样做的成本很高而且逻辑上也比较复杂。
容器查询就是为了解决这个问题而诞生的，它的基本思想是让元素可以查询到最近的包含它的祖先容器，并且按照这个容器的尺寸来进行样式的应用。在使用之前要先定义好容器：给父级元素加上container-type属性，常见的取值有inline-size（只考虑宽度）和size（综合考虑宽高），也可以给容器起个名字以便在多个容器同时存在的时候进行准确的匹配。
典型的容器查询写法就是：父元素给容器类型设为inline-size、容器名设为card；子元素中用@container card (min-width: 400px) {…}来表示当卡片容器宽度为400px的时候，里面的布局会从垂直排列变成水平排列。整个过程都是靠CSS完成的，并不需要用到JavaScript或者视口大小来判断是否要改变样式。也就是说不管把这张卡片放在哪里，只要它的父元素满足这个条件的话，它的样式就会自动进行调整。
容器查询与媒体查询不是相互排斥的关系，而是相辅相成的关系。媒体查询适用于整个页面的大尺度布局调整，例如移动端的导航栏折叠以及桌面端展开；而容器查询则用于单个元素的小尺度适配，如卡片、按钮组、表单行等。二者结合使用可以使响应式系统既具备整体规划的能力又拥有局部的灵活性。
从2023年开始，主流浏览器都已经支持了容器查询功能，包括Chrome 105、Safari 16和Firefox 110等。如果要兼容旧版浏览器，则可以利用@supports进行特性检测，并给出相应的降级方案。降级的意思是让组件默认使用一种合理的布局方式，在支持容器查询的情况下再开启更细致的适配模式。
从性能的角度来看，容器的开销主要是由于containment引起的渲染隔离造成的。正确运用container-type可以减小重排范围，从而提升性能。但是不能滥用它，在一个页面中如果有几百个元素都被标记为容器的话，那么浏览器就要维护很多尺寸观察器了，这反而是不利的。所以只应该在需要按照容器大小来调整样式的组件上使用。
由原来的媒体查询转变为现在的容器查询之后，响应式布局的粒度就由整个页面降到了单个元素上。这给开发者带来了更多的技术选择，并且也改变了他们的思维方式——不再假定自己的位置在哪种屏幕上，而是根据实际所处的空间来进行调整。这对于构建设计系统、组件库以及跨平台的页面来说非常重要。先打好媒体查询的基础再慢慢加入容器查询来解决复杂的情况是目前最安全的方式。
