生成式卡片的响应式布局：断点应该看容器，不只看窗口

同一张订单卡片，放进全宽工作台没有问题，嵌入右侧抽屉却被挤成一团。浏览器窗口没有变窄，媒体查询自然不会替你解释这个局部变化。生成式UI把卡片放到越来越多的宿主里，布局的边界也应该跟着宿主走。

CSS Containment Level 3给出了容器查询相关机制。这里用它解决一个具体问题：卡片自身不知道会被放到哪里，但它可以根据可用的内联尺寸改变字段列数。

容器与被查询元素不要混在同一层

给外层建立查询容器，在里面调整卡片布局。先提供不依赖查询的单列样式，再让支持相关能力的浏览器增强为多列。断点只是这个示例的设计选择，不是行业标准。

下面是一个完整HTML页面，可以直接保存后打开。拖动浏览器窗口或修改.host的宽度，即可观察列数。这里只放固定内容，用来检查布局；真实流式协议应单独接入。

<!doctype html> <html lang="zh-CN"> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>容器内的生成式卡片</title> <style> body { margin: 24px; font: 16px/1.6 system-ui; } .host { container-type: inline-size; max-width: 70rem; } .card { display: grid; gap: 1rem; padding: 1rem; border: 1px solid #456; border-radius: 8px; } label { min-width: 0; } input { display: block; box-sizing: border-box; width: 100%; min-width: 0; padding: .5rem; font: inherit; } @container (min-width: 32rem) { .card { grid-template-columns: repeat(2, minmax(0, 1fr)); } } @container (min-width: 52rem) { .card { grid-template-columns: repeat(3, minmax(0, 1fr)); } } </style> <main class="host"> <form class="card"> <label>姓名<input name="name" autocomplete="name"></label> <label>城市<input name="city" autocomplete="address-level2"></label> <label>备注<input name="note"></label> </form> </main> </html>

minmax(0, 1fr)和控件的min-width: 0是为了让长内容有收缩空间，不是为内容截断免责。错误提示、长地名和较大字号也需要进入测试。业务关键文字不应为了维持一张“整齐卡片”而被隐藏。

流式到达与布局变化，是两条轴

10月更新的WebMCP文档仍强调可见的网页交互。无论内容由Agent还是用户触发，新增字段都不应夺走正在输入的焦点。保持稳定字段ID，避免把整张表单销毁重建；尚未到达的字段可以保留合理占位，但不要承诺一个无法预测的固定总高度。

图片尚未下载时预留宽高比；文字自然增长时允许页面延展；用户已经向上阅读时停止自动跟随。容器查询解决的是空间分配，不负责这些交互状态，也不保证CLS必然为零。

这份HTML未在浏览器中实际打开或完成无障碍测试，未验证各浏览器版本的兼容矩阵。它没有真实模型、翻译和流式网络依赖，接入生产前仍需覆盖窄容器、放大字号、键盘焦点和长文本。