AI 摘要：本文系统梳理了 CSS 中 Container Queries 的三种类别（包括 Container Size Queries、Style Queries、Scroll-state Queries），重点介绍了已在主流浏览器实现的“尺寸查询”特性如何革新组件级响应式设计，但也提醒开发者——这并非替代 Media Queries 的“银弹”。文章从语法、性能约束、浏览器支持到设计协作与可访问性进行了深入分析，最后指出未来 2026 年 Style Queries 或将迎来实用化拐点。

1. 背景与概念：Container Queries 是什么
• 源自对 Media Queries 局限的反思，核心思想是“基于容器上下文，而非视口”进行样式判断。
• 三种类型：
• Container Size Queries：按父容器尺寸调整样式（目前最成熟）。
• Container Style Queries：根据容器的样式属性触发响应（仍在实验阶段）。
• Container Scroll-state Queries：随滚动状态变化触发样式。
• 支持组件级响应，使组件可在任意布局中自适应。

2. 工作机制与核心语法
• 使用 container-type 属性显式声明容器上下文（如 inline-size）。
• @container 规则用于监听容器尺寸条件。
• 支持逻辑方向单位（inline/block），替代传统 width、height。
• 新增容器单位 (container query units)：如 cqw, cqh, cqi, cqb，与 viewport 单位类似但基于容器。
• 通过 container-name 可命名容器，以便管理嵌套查询。

3. 性能与限制（containment API 的作用）
• Container Queries 得以实现的关键是 Containment API。
• 为避免性能开销，每个容器需“选择加入”（opt-in），阻止布局循环。
• 限制与陷阱：
• 无法查询自身，只能作用于子级。
• 某些布局（如 Flexbox）可能需额外约束尺寸。
• 不支持在查询条件中使用自定义变量（custom properties）。
• 过度嵌套可能导致标记膨胀。

4. 三种 Query 类型的详细分析
• Size Queries：主流实现，支持全面，能显著提升组件自治性。
• Style Queries：基于容器样式或 CSS 自定义属性触发；浏览器支持尚不完善，未来版本（尤其 Firefox）有望实装。
• Scroll-state Queries：根据 stuck、snapped、scrollable 等状态调整布局；适合渐进增强。

5. 与 Media Queries 的关系
• 非替代关系，而是互补：
• Media Queries 仍主导宏观布局与可访问性偏好（如 print、暗色模式）。
• Container Queries 主攻微观层级的组件自适应。
• 建议联合使用，例如嵌套 @media 与 @container 以实现双层响应策略。

6. 可访问性与可维护性
• 需确保布局变化不破坏键盘导航与阅读顺序。
• 避免大幅度 layout shift，必要时使用 aria-live。
• 适度使用 Container Queries，防止性能问题；合理划分 @container 层级。

7. 浏览器支持现状与未来展望（至 2026）
• 2023 起 主流浏览器已全面支持 Size Queries。
• 2025 末 Chrome、Edge、Opera 支持 Scroll-state；Firefox 预计 2026 跟进 Style Queries。
• CSS 社区使用率增长缓慢（2025 调查：仅 7% 使用 Style Queries）。
• 预期 2026 年将成为“容器查询元年”，尤其设计工具（如 Figma）与开发端联动增强后。

8. 实践与工具链建议
• 设计师应从视口（viewport-centric）转向容器思维（container-centric）。
• 前端可在 DevTools 中可视化调试容器边界与查询状态。
• 借助 @supports 可实现渐进增强。
• 结合组件化体系（React、Vue 等）可真正实现“自包含组件”(self-contained components)。

9. 结论：强大但非万能
• 容器查询填补了响应式开发的关键空白，使组件具备上下文感知能力。
• 然而仍需注意性能、兼容性和可访问性。
• 它们不会消灭媒体查询，但将共同构建未来的“模块化响应式设计”范式。

LogRocket Blog

Container queries in 2026: Powerful, but not a silver bullet - LogRocket Blog

Container queries enable truly responsive components. Learn how they work, where they shine, and why they complement rather than replace media queries.

AI 摘要： 作者 Nolan Lawson 在假期挑战自己以 “vibe coding” （即尽量不亲自写代码、主要通过 LLM 助手生成）构建一个供妻子使用的旅行行程管理 Web 应用。项目利用 Claude Code、Tailwind CSS、React、PocketBase 与 Railway 进行快速开发，最终成果稳定且满足需求。但实践暴露出当前 LLM 编码工具的不足：非程序员难以高效运用、可访问性差、性能优化需要人工介入。作者反思 “vibe coding” 的局限，也看到其在轻量、个性化应用中的潜力，并对未来软件开发职业与 AI 协作形态表示复杂的期待与忧虑。

Read the Tea Leaves

An experiment in vibe coding

For the holidays, I gave myself a little experiment: build a small web app for my wife to manage her travel itineraries. I challenged myself to avoid editing the code myself and just do it “v…

Sujen Phea (@sujen_p): Unfurling paper
Demo 👉 https://paper-scroll.sujen.co/
#webgl #threejs
Spinning disco vibes
Demo 👉 https://disco.sujen.co
#webgl #threejs

AI 摘要：Chrome 143+ 引入 CSS 锚点定位回退检测机制，可自动检测容器布局变化并动态切换定位方向，解决传统锚点定位在空间受限时的显示异常问题。

AI 摘要：Waku 是一个专注于静态与动态混合渲染的 React 框架，现已发布 1.0-alpha 版本并标记公共 API 为稳定状态。该框架特别适合构建营销网站、博客、文档站和轻量级电商等大部分静态内容但包含少量动态路由的场景。Waku 提供灵活的路由配置方式（文件路由和配置路由），支持在布局、切片和页面级别独立设置渲染配置，可实现静态渲染、动态渲染或混合渲染。团队后续将专注于 bug 修复和兼容性改进，并为每个版本提供发布说明和迁移指南。

Waku

Waku 1.0 (alpha) — Waku

Waku's public APIs are now marked as stable.

AI 摘要：本文深入探讨了如何利用 CSS 实现元素在滚动时从 position: sticky 切换到 position: fixed 的视觉效果。文章提供了两种主要方法：一是结合 view() 函数和 keyframes 实现基于滚动驱动的动画，详细讲解了布局、相对尺寸设置（使用容器查询单位 cqw）以及如何精确调整元素位置以避免切换时的跳动；二是利用尚处于实验阶段的滚动状态查询 (scroll-state)，这种方法代码量更少，但浏览器兼容性较差。文章强调了在两种定位模式下保持元素尺寸和位置的连贯性是实现流畅过渡的关键，并讨论了这种效果在用户界面（如 CTA 按钮、横幅）中的实际应用场景。

使用自定义模型实现粒子爆炸，精确地限定在圆柱体内。
演示 particles.sujen.co

AI 摘要：作者从一个“反 AI 狂热者”转变为 AI 代理的使用者，因为他发现 AI 在代码编写上的生产力惊人。他详细介绍了如何设置 AI 代理（以 Claude Code 为例），强调了配置清晰的 CLAUDE.md 文件（包括项目架构和个人编码习惯）的重要性。在整体策略上，他强调了结合自动化测试提供反馈循环，以及在复杂任务中使用“计划模式”来让 AI 进行思考。作者还分享了处理 AI 常见错误（如删除注释、代码重复）的方法，即开启新会话让 AI 进行“代码审查”。此外，他还提到 AI 代理能在夜间持续工作，实现“睡着也能完成额外工作”的优势。尽管作者对 AI 代理仍抱有复杂情感，认为它们剥夺了编程乐趣，但他承认 AI 显著提升了编码效率，将自己的角色比作软件架构师，主要负责设计和审查，而非亲手编写所有代码。

1. 对 AI 编码态度的转变
• 从“反 AI 狂热者”到接受者：作者承认尽管曾强烈反对 AI，但其同事的生产力提升以及 AI 工具（如 Claude Code、OpenAI Codex、Gemini CLI）的发布，使其无法再忽视。
• 承认 AI 的高效性：尽管作者有 20 年的编程经验和对代码质量的“老派”看法，但 AI 在许多时候比他写得更好。
• 强调正确使用 AI：将 AI 比作“锋利的菜刀与电锯的组合”，强调不当使用可能造成伤害。

2. AI 代理的基本设置
• 选择工具：作者主要使用 Claude Code，因其足够好用，虽然市面上有许多其他选择。
• CLAUDE.md 文件的作用：
• 项目级 CLAUDE.md：用于描述项目概况、整体架构、注意事项等，帮助 AI 理解代码库。
• 个人级 CLAUDE.md：记录个人编码习惯和偏好（例如：在 map() 或 filter() 函数中使用 _ 变量名）。

3. 整体使用策略
• 吸取教训：作者承认在 AI 上浪费了大量时间，AI 代理可能会“引你走弯路”，导致创建出“勉强能用”的“怪物”。
• 建立反馈循环：
• 自动化测试：通过自动化测试让 AI 代理验证其解决方案，纠正错误。
• “计划模式”（plan mode）：对于复杂任务，让 AI 在执行前先“思考”并制定计划，可以有效避免盲目尝试。
• AI 在 UI 方面的局限性：AI 在处理 UI 任务时效率较低，因为需要消耗大量 token 进行 DOM 检查或通过截屏检查，导致速度缓慢且容易出错。

4. 处理 AI 产生的错误
• AI 常见的错误类型：
• 删除有用的注释：将重要信息移除或修改。
• 代码重复：AI 代理倾向于复制粘贴代码，违反 DRY (Don't Repeat Yourself) 原则。
• 引入细微的错误：在重构时无意中改变代码原意（例如：添加多余的空值检查）。
• 解决策略：
• 重启会话进行“代码审查”：开启新的 AI 会话，让其对比 origin/main 进行纯重构检查，并查找功能性错误。
• 伪装代码来源：为了获得更客观的反馈，可以谎称审查的是同事的 PR (Pull Request)。
• 重复检查：多次运行相同的审查流程，确保所有错误都被发现和修复。

5. AI 带来的额外价值
• “睡着也能完成额外工作”：AI 代理不知疲倦，可以持续迭代解决问题，为作者节省时间。
• “自动化盲区”（automation blindness）的风险：长时间对 AI 的输出无条件“同意”，可能导致忽视潜在问题。
• “yolo 模式”下的试验：在 Podman 容器中运行 AI 代理，以减少对人工干预的依赖，但作者仅在不重要的副项目中使用，以防潜在的安全问题。
• 工作与生活平衡的挑战：AI 可能导致工作侵入非工作时间，需警惕。

6. 结论与个人感受
• 复杂的情感：作者对 AI 代理仍抱有复杂甚至“厌恶”的情感，认为它们让编程变得不那么有趣，但其有效性是不可否认的。
• 效率的巨大提升：AI 极大地提高了代码编写速度。
• 适用场景：AI 不适合处理复杂、新颖或涉及代码库多个分散部分的模糊项目，这类任务仍需人工完成。
• 角色转变：作者将自己的新角色比作软件架构师，更多地参与规范编写和代码审查，而非纯粹的编码。
• 对开源项目的影响：作者在开源项目中不使用 AI，因为缺乏“所有权”感，认为代码不是自己亲手写的。
• “不那么有趣，但最优”的选择：尽管 AI 让编程乐趣减少，但它作为“最优策略”，仍会被选择使用，就像游戏中玩家会选择最有效率而非最有趣的玩法。
• 接受现状：作者认为大多数开发者已经接受 AI，并正在向前发展。