摘要

  • W3C 在 2021 年 12 月 21 日发布 CSS Containment Level 3 第一版公开草案，把对页面内元素的查询与对浏览器环境的媒体查询区分开来。container-type 建立可查询的容器，@container 依据条件给后代元素应用样式。
  • 2022 年 8 月 18 日的工作草案细化了尺寸查询、命名容器和相对单位。它用正文区域与边栏中的同一组件，展示局部宽度如何决定布局。

这张卡片原本挺有排场。正文宽栏让图片与标题并肩站着，下面还有空间给简介。到了边栏，图片和文字被塞进同一条窄缝，像搬家时把双人沙发硬推进储物间。设计师看着浏览器：窗口很宽啊。卡片看着自己的边栏：与我何干？媒体查询测到的是整扇窗，卡片需要的是眼前这块地。

W3C 于 2021 年 12 月 21 日发布的第一版公开草案把问题分成两种尺度。媒体查询询问用户代理或设备环境，包括视口尺寸；容器查询询问文档内部元素的盒子尺寸等属性。一个组件可以在同一屏幕上出现好几次，分别落在宽栏、边栏或嵌套模块里。给它们同一条“窗口很宽”的指令，等于给每个房间都订一张按整栋楼尺寸做的地毯。

容器查询先确定谁提供尺寸。页面作者用 container-type 标记合适的祖先元素，再用 @container 写条件；条件成立，后代元素才采用相应样式。宽容器里让图片与文字横排，窄容器里改为上下堆叠。同一浏览器窗口内，两张相同卡片可以各自排得体面。发布者决定把卡片放在哪里，浏览器在每个位置读当地的尺度。

这把尺需要稳固的边界。假如容器宽度又取决于子元素，而子元素布局取决于容器宽度，测量便会绕圈。W3C 在 2021 年的架构演示讲到建立查询容器，并在需要时切断内容决定自身尺寸的路径。容纳规则让父盒子的尺寸成为可用的输入，后代才有办法据此选择样式。局部自由建立在明确边界之上。

2022 年 8 月 18 日的工作草案直接给出正文区和边栏的例子：同一个媒体对象随容器尺寸在竖排与横排之间切换。container-type: inline-size 使祖先具备沿行内轴接受尺寸查询的资格；容器名称还能帮助 @container 指向指定的祖先。条件作用于那个容器里的后代，组件因此按所在位置着装。

草案还定义 cqw、cqi 等相对长度单位，分别把尺寸与查询容器的宽度、行内尺寸联系起来。卡片搬家时，内部比例也能跟着新的房间走。W3C CSS 工作组的2022 年更新公告把行内尺寸容纳、查询规则和这些单位列为同一组设计。

从 2021 到 2022，规则本身也在量体裁衣。早期草案探索了 block-size、state 等类型；后来的版本移除了单轴 block-size 选项，并调整初始值和简写语法。W3C 的发布历史记录了这两个版本。真正留下的主线很清楚：让组件询问可用的本地空间，而不是猜测整个页面会把它安放在哪里。

浏览器窗口仍旧宽敞，边栏仍旧狭窄。CSS 终于允许那张卡片承认自己的住址。它不用为整个网站买一套新衣，只须按眼前房间的尺寸重新穿好。