Front-End-Checklist 容器查询规则用 container 打造真正可复用的组件级响应式布局【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist在 Front-End-Checklist 的 CSS 规则体系中container-queries规则优先级 medium、难度 intermediate、预计耗时 20 分钟教给开发者和 AI Agent 一个核心能力让组件根据自身容器的尺寸而非视口宽度来自适应布局。读完本篇你将掌握container-type的设置方式、container断言语法、命名容器与容器单位cqi/cqw/cqmin 等的完整用法并理解该规则如何被仓库中的 MCP 代码审查工具自动检测和验证。为什么需要容器查询媒体查询的“上下文依赖”问题媒体查询media的断言对象是视口宽度这导致组件天然带有上下文依赖一张为 3 列网格设计的卡片一旦被放进 2 列网格或侧边栏布局就可能破碎。容器查询解决了这个问题——卡片可以根据容器实际分配给它的空间自行决定布局从而在侧边栏、网格、全宽区域等任何布局上下文中都保持可用。这正是 规则页面 中whyItMatters字段给出的核心论断容器查询让组件“genuinely reusable in any layout context”在任何布局上下文中真正可复用。基础用法父元素定义容器子元素查询容器容器查询的完整工作模式分两步在父元素上定义容器在子元素上查询容器。这是 rules 参考文档 给出的标准代码示例/* 1. Define the container on the PARENT */ .card-container { container-type: inline-size; /* Optionally name it */ container-name: card; /* Shorthand */ container: card / inline-size; } /* 2. Query the container from the CHILD */ container (min-width: 400px) { .card { display: flex; gap: 1.5rem; } .card__image { flex: 0 0 200px; } }要点拆解container-type: inline-size是启用容器查询的前提写在父级元素上container-name简写为container: card / inline-size给容器命名供后续精确指定目标container (min-width: 400px)的断言条件是最近命名容器的 inline 尺寸而非视口当容器宽度达到 400px 时卡片切换为横向 flex 布局。命名容器在多个祖先容器中精确寻址当页面上存在多个容器如侧边栏与主内容区时匿名container只匹配最近的容器而命名容器允许你在断言中指名道姓地针对特定祖先/* Name containers to target specific ancestors */ .sidebar { container: sidebar / inline-size; } .main-content { container: main / inline-size; } /* Target the sidebar container specifically */ container sidebar (max-width: 300px) { .widget { font-size: 0.875rem; } } container main (min-width: 800px) { .article { column-count: 2; } }这个模式的价值在于同一个.widget组件在侧边栏中缩小字号而主文章区在宽度足够时开启双栏排版——两条规则互不干扰因为container sidebar与container main各自只匹配对应命名的容器。实战案例三档自适应的卡片组件参考文档 中给出的“Real-World Card Component”展示了容器查询最典型的应用一张卡片在任意位置侧边栏、网格、全宽都能根据可用空间切换三档布局/* The card works anywhere — sidebar, grid, full-width */ .card-wrapper { container-type: inline-size; } .card { /* Stacked layout by default (narrow context) */ display: grid; gap: 1rem; } .card__image { aspect-ratio: 16 / 9; } /* Side-by-side layout when theres enough room */ container (min-width: 480px) { .card { grid-template-columns: 200px 1fr; align-items: start; } .card__image { aspect-ratio: 1; } } /* Richer layout at wide sizes */ container (min-width: 720px) { .card { grid-template-columns: 320px 1fr; } .card__meta { display: flex; gap: 1rem; } }三档布局策略值得注意默认档窄容器grid 纵向堆叠图片保持 16:9 宽高比480px 档图片与正文并排200px 固定图列 1fr 文本列图片切换为 1:1720px 档图列加宽到 320px元信息区.card__meta展开为横向 flex。关键在于断言基准是.card-wrapper的宽度同一张卡片放进 360px 的侧边栏时永远停在第一档放进 1200px 的全宽区域则自动升到第三档——无需为每种页面布局单独写媒体查询。container-type 的三种取值container-type决定元素是否成为容器以及可查询的维度container-type: normal; /* Default — not a container */ container-type: inline-size; /* Queries based on inline (usually width) dimension */ container-type: size; /* Queries based on both inline and block dimensions */normal默认值元素不是容器inline-size最常用仅暴露 inline 维度横排书写方向下即宽度供查询。注意它会使元素产生类似contain: inline-size的布局隔离——元素的 inline 尺寸不再依赖子元素内容size同时暴露 inline 与 block 两个维度因此可以使用min-height/max-height等 block 维度断言但代价是元素的两个维度都必须显式确定不能由子元素撑开使用受限较多实践中优先选择inline-size。容器单位随容器缩放的比例单位除了断言容器查询还引入了一组容器查询单位让字号、间距等声明随容器尺寸连续缩放而非在断言点跳变/* Relative to the nearest container */ .responsive-text { font-size: clamp(1rem, 4cqi, 2rem); /* cqi 1% of containers inline size */ /* cqb 1% of containers block size */ /* cqw, cqh same but always width/height */ /* cqmin, cqmax minimum/maximum of the two */ }六个单位一览单位基准说明cqi容器 inline 尺寸随书写方向通常等于宽度cqb容器 block 尺寸随书写方向通常等于高度cqw容器宽度始终按物理宽度计算cqh容器高度始终按物理高度计算cqmin两者较小值等价于 CSS 全局单位min()的语义cqmax两者较大值等价于 CSS 全局单位max()的语义示例中clamp(1rem, 4cqi, 2rem)的含义是字号跟随容器的 4% 线性缩放并限制在 1rem2rem 之间——容器查询单位与clamp()配合是替代“字号断言阶梯”的平滑方案。与 CSS Containment 的关系container-type 自动设置隔离规则页面 的relatedRules明确将css-containment列为关联规则理由是“Container queries require containment — container-type automatically sets it”容器查询依赖隔离container-type会自动设置它。这一点在 css-containment 规则文档 中得到呼应contain: inline-size的取值注释即为 “Inline size is independent (for container queries)”。这意味着给元素设置container-type: inline-size时浏览器隐式施加了 inline-size 方向的布局隔离容器内部的布局变化不会向外传播容器尺寸的计算也不再依赖子元素。这一机制是容器查询能够保证布局稳定性的底层原因同时也是使用时的注意事项——如果某个祖先元素本应被子元素内容撑开高度直接对它启用容器类型会改变其行为这是引入容器查询后最常见的副作用来源。浏览器支持与项目支持数据的自动化参考文档 的 Support Notes 给出该规则在当前仓库的支持基线该特性在项目当前浏览器矩阵上受支持Baseline 兼容最低版本为chrome 115、edge 115、firefox 116、safari 16.4、safari_ios 16.4当项目必需的目标浏览器落在此支持范围之外时应补充回退或渐进增强说明。这些数字并非手写维护而是由仓库的脚本管线从权威数据源计算得出。从 rule-support-data.ts 的源码可以看到规则 slug 被映射到 MDN Browser Compat Data 的特性 IDconst RULE_SUPPORT_FEATURE_MAP: Recordstring, string { // ... container-queries: css.at-rules.container, // ... }getRuleSupportData 函数则以项目browserslist配置解析出的目标浏览器列表为输入对照 BCD 数据标记出不受支持的目标并从baseline-browser-mapping包读取 Baseline 最低版本。也就是说文档中“supported across the current project browser matrix”这句结论是从项目的浏览器目标配置与 BCD 兼容性数据比对后生成的事实适用前提正是项目browserslist配置所声明的浏览器范围。规则在 MCP 审查工具中的自动检测该规则在仓库中不只是一篇文档——MCP 工具包 的代码审查工具内置了对应的启发式检测逻辑。在 review-code.ts 中// Container queries — modern responsive alternative to media queries if (slug.includes(container-queries) || slug.includes(container-query)) { const mediaQueries (code.match(/media\s/gi) || []).length const containerQueries (code.match(/container\s/gi) || []).length if ( mediaQueries MEDIA_QUERY_THRESHOLD containerQueries 0 lowerCode.includes(component) ) { return { hasIssue: true, issue: Found component-scoped CSS with media queries but no container queries (consider container queries for component-level responsiveness) } } }配合阈值定义 MEDIA_QUERY_THRESHOLD 3“3 media queries before suggesting container for component-scoped CSS”可以完整读出该工具的判定条件当被审查的组件级 CSS 中出现超过 3 条media断言、且没有任何container断言时工具会报告问题并建议改用容器查询实现组件级响应式。这与规则文档“Check”环节的指引——“Look for components in this CSS that have media query breakpoints — consider whether container queries would make them more reusable”——完全一致人工审查与机器启发式共用同一判断标准。Skill 工作流Check / Fix / Explain / Code Review仓库中对应的 SKILL.md 为 Agent 定义了四个标准动作可作为人工自查清单直接复用Check查找样式中带有媒体查询断点的组件评估改用容器查询是否能让其在不同布局上下文中更可复用Fix将组件从基于媒体查询的响应式用container-type与container改造为基于容器查询的响应式Explain解释容器查询与媒体查询的区别、为何容器查询带来更好的组件复用以及如何建立“容器/查询”的父子关系Code Review审查与容器查询相关的样式表、组件样式与响应式状态标记出在渲染结果中违反该规则的精确选择器、声明或断点。验证清单在提交修改前参考文档 要求完成以下验证步骤在受该规则影响的断点与交互状态下检查渲染后的 UI在 DevTools 中确认计算样式computed styles与预期修复一致上线前至少测试一个移动端视口和一个桌面端视口如果规则影响到动效、对比度或布局稳定性需直接验证这些面向用户的表现。小结container-queries规则的核心脉络可以概括为一条链路父元素container-type: inline-size定义容器并隐式获得 inline-size 隔离→ 子元素用container断言按容器尺寸切换布局 → 用命名容器在多容器页面精确寻址 → 用cqi/cqmin等单位实现平滑缩放 → 按项目的浏览器目标与 Baseline 版本chrome 115 / firefox 116 / safari 16.4 等确认兼容性。仓库中从 规则内容、Agent Skill 到 MCP 自动检测 与 支持数据脚本围绕同一条规则形成了“文档—自动化—验证”的完整闭环这套模式对理解 Front-End-Checklist 的规则工程化设计也有参考价值。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Front-End-Checklist 容器查询规则：用 @container 打造真正可复用的组件级响应式布局
Front-End-Checklist 容器查询规则用 container 打造真正可复用的组件级响应式布局【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist在 Front-End-Checklist 的 CSS 规则体系中container-queries规则优先级 medium、难度 intermediate、预计耗时 20 分钟教给开发者和 AI Agent 一个核心能力让组件根据自身容器的尺寸而非视口宽度来自适应布局。读完本篇你将掌握container-type的设置方式、container断言语法、命名容器与容器单位cqi/cqw/cqmin 等的完整用法并理解该规则如何被仓库中的 MCP 代码审查工具自动检测和验证。为什么需要容器查询媒体查询的“上下文依赖”问题媒体查询media的断言对象是视口宽度这导致组件天然带有上下文依赖一张为 3 列网格设计的卡片一旦被放进 2 列网格或侧边栏布局就可能破碎。容器查询解决了这个问题——卡片可以根据容器实际分配给它的空间自行决定布局从而在侧边栏、网格、全宽区域等任何布局上下文中都保持可用。这正是 规则页面 中whyItMatters字段给出的核心论断容器查询让组件“genuinely reusable in any layout context”在任何布局上下文中真正可复用。基础用法父元素定义容器子元素查询容器容器查询的完整工作模式分两步在父元素上定义容器在子元素上查询容器。这是 rules 参考文档 给出的标准代码示例/* 1. Define the container on the PARENT */ .card-container { container-type: inline-size; /* Optionally name it */ container-name: card; /* Shorthand */ container: card / inline-size; } /* 2. Query the container from the CHILD */ container (min-width: 400px) { .card { display: flex; gap: 1.5rem; } .card__image { flex: 0 0 200px; } }要点拆解container-type: inline-size是启用容器查询的前提写在父级元素上container-name简写为container: card / inline-size给容器命名供后续精确指定目标container (min-width: 400px)的断言条件是最近命名容器的 inline 尺寸而非视口当容器宽度达到 400px 时卡片切换为横向 flex 布局。命名容器在多个祖先容器中精确寻址当页面上存在多个容器如侧边栏与主内容区时匿名container只匹配最近的容器而命名容器允许你在断言中指名道姓地针对特定祖先/* Name containers to target specific ancestors */ .sidebar { container: sidebar / inline-size; } .main-content { container: main / inline-size; } /* Target the sidebar container specifically */ container sidebar (max-width: 300px) { .widget { font-size: 0.875rem; } } container main (min-width: 800px) { .article { column-count: 2; } }这个模式的价值在于同一个.widget组件在侧边栏中缩小字号而主文章区在宽度足够时开启双栏排版——两条规则互不干扰因为container sidebar与container main各自只匹配对应命名的容器。实战案例三档自适应的卡片组件参考文档 中给出的“Real-World Card Component”展示了容器查询最典型的应用一张卡片在任意位置侧边栏、网格、全宽都能根据可用空间切换三档布局/* The card works anywhere — sidebar, grid, full-width */ .card-wrapper { container-type: inline-size; } .card { /* Stacked layout by default (narrow context) */ display: grid; gap: 1rem; } .card__image { aspect-ratio: 16 / 9; } /* Side-by-side layout when theres enough room */ container (min-width: 480px) { .card { grid-template-columns: 200px 1fr; align-items: start; } .card__image { aspect-ratio: 1; } } /* Richer layout at wide sizes */ container (min-width: 720px) { .card { grid-template-columns: 320px 1fr; } .card__meta { display: flex; gap: 1rem; } }三档布局策略值得注意默认档窄容器grid 纵向堆叠图片保持 16:9 宽高比480px 档图片与正文并排200px 固定图列 1fr 文本列图片切换为 1:1720px 档图列加宽到 320px元信息区.card__meta展开为横向 flex。关键在于断言基准是.card-wrapper的宽度同一张卡片放进 360px 的侧边栏时永远停在第一档放进 1200px 的全宽区域则自动升到第三档——无需为每种页面布局单独写媒体查询。container-type 的三种取值container-type决定元素是否成为容器以及可查询的维度container-type: normal; /* Default — not a container */ container-type: inline-size; /* Queries based on inline (usually width) dimension */ container-type: size; /* Queries based on both inline and block dimensions */normal默认值元素不是容器inline-size最常用仅暴露 inline 维度横排书写方向下即宽度供查询。注意它会使元素产生类似contain: inline-size的布局隔离——元素的 inline 尺寸不再依赖子元素内容size同时暴露 inline 与 block 两个维度因此可以使用min-height/max-height等 block 维度断言但代价是元素的两个维度都必须显式确定不能由子元素撑开使用受限较多实践中优先选择inline-size。容器单位随容器缩放的比例单位除了断言容器查询还引入了一组容器查询单位让字号、间距等声明随容器尺寸连续缩放而非在断言点跳变/* Relative to the nearest container */ .responsive-text { font-size: clamp(1rem, 4cqi, 2rem); /* cqi 1% of containers inline size */ /* cqb 1% of containers block size */ /* cqw, cqh same but always width/height */ /* cqmin, cqmax minimum/maximum of the two */ }六个单位一览单位基准说明cqi容器 inline 尺寸随书写方向通常等于宽度cqb容器 block 尺寸随书写方向通常等于高度cqw容器宽度始终按物理宽度计算cqh容器高度始终按物理高度计算cqmin两者较小值等价于 CSS 全局单位min()的语义cqmax两者较大值等价于 CSS 全局单位max()的语义示例中clamp(1rem, 4cqi, 2rem)的含义是字号跟随容器的 4% 线性缩放并限制在 1rem2rem 之间——容器查询单位与clamp()配合是替代“字号断言阶梯”的平滑方案。与 CSS Containment 的关系container-type 自动设置隔离规则页面 的relatedRules明确将css-containment列为关联规则理由是“Container queries require containment — container-type automatically sets it”容器查询依赖隔离container-type会自动设置它。这一点在 css-containment 规则文档 中得到呼应contain: inline-size的取值注释即为 “Inline size is independent (for container queries)”。这意味着给元素设置container-type: inline-size时浏览器隐式施加了 inline-size 方向的布局隔离容器内部的布局变化不会向外传播容器尺寸的计算也不再依赖子元素。这一机制是容器查询能够保证布局稳定性的底层原因同时也是使用时的注意事项——如果某个祖先元素本应被子元素内容撑开高度直接对它启用容器类型会改变其行为这是引入容器查询后最常见的副作用来源。浏览器支持与项目支持数据的自动化参考文档 的 Support Notes 给出该规则在当前仓库的支持基线该特性在项目当前浏览器矩阵上受支持Baseline 兼容最低版本为chrome 115、edge 115、firefox 116、safari 16.4、safari_ios 16.4当项目必需的目标浏览器落在此支持范围之外时应补充回退或渐进增强说明。这些数字并非手写维护而是由仓库的脚本管线从权威数据源计算得出。从 rule-support-data.ts 的源码可以看到规则 slug 被映射到 MDN Browser Compat Data 的特性 IDconst RULE_SUPPORT_FEATURE_MAP: Recordstring, string { // ... container-queries: css.at-rules.container, // ... }getRuleSupportData 函数则以项目browserslist配置解析出的目标浏览器列表为输入对照 BCD 数据标记出不受支持的目标并从baseline-browser-mapping包读取 Baseline 最低版本。也就是说文档中“supported across the current project browser matrix”这句结论是从项目的浏览器目标配置与 BCD 兼容性数据比对后生成的事实适用前提正是项目browserslist配置所声明的浏览器范围。规则在 MCP 审查工具中的自动检测该规则在仓库中不只是一篇文档——MCP 工具包 的代码审查工具内置了对应的启发式检测逻辑。在 review-code.ts 中// Container queries — modern responsive alternative to media queries if (slug.includes(container-queries) || slug.includes(container-query)) { const mediaQueries (code.match(/media\s/gi) || []).length const containerQueries (code.match(/container\s/gi) || []).length if ( mediaQueries MEDIA_QUERY_THRESHOLD containerQueries 0 lowerCode.includes(component) ) { return { hasIssue: true, issue: Found component-scoped CSS with media queries but no container queries (consider container queries for component-level responsiveness) } } }配合阈值定义 MEDIA_QUERY_THRESHOLD 3“3 media queries before suggesting container for component-scoped CSS”可以完整读出该工具的判定条件当被审查的组件级 CSS 中出现超过 3 条media断言、且没有任何container断言时工具会报告问题并建议改用容器查询实现组件级响应式。这与规则文档“Check”环节的指引——“Look for components in this CSS that have media query breakpoints — consider whether container queries would make them more reusable”——完全一致人工审查与机器启发式共用同一判断标准。Skill 工作流Check / Fix / Explain / Code Review仓库中对应的 SKILL.md 为 Agent 定义了四个标准动作可作为人工自查清单直接复用Check查找样式中带有媒体查询断点的组件评估改用容器查询是否能让其在不同布局上下文中更可复用Fix将组件从基于媒体查询的响应式用container-type与container改造为基于容器查询的响应式Explain解释容器查询与媒体查询的区别、为何容器查询带来更好的组件复用以及如何建立“容器/查询”的父子关系Code Review审查与容器查询相关的样式表、组件样式与响应式状态标记出在渲染结果中违反该规则的精确选择器、声明或断点。验证清单在提交修改前参考文档 要求完成以下验证步骤在受该规则影响的断点与交互状态下检查渲染后的 UI在 DevTools 中确认计算样式computed styles与预期修复一致上线前至少测试一个移动端视口和一个桌面端视口如果规则影响到动效、对比度或布局稳定性需直接验证这些面向用户的表现。小结container-queries规则的核心脉络可以概括为一条链路父元素container-type: inline-size定义容器并隐式获得 inline-size 隔离→ 子元素用container断言按容器尺寸切换布局 → 用命名容器在多容器页面精确寻址 → 用cqi/cqmin等单位实现平滑缩放 → 按项目的浏览器目标与 Baseline 版本chrome 115 / firefox 116 / safari 16.4 等确认兼容性。仓库中从 规则内容、Agent Skill 到 MCP 自动检测 与 支持数据脚本围绕同一条规则形成了“文档—自动化—验证”的完整闭环这套模式对理解 Front-End-Checklist 的规则工程化设计也有参考价值。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考