Chrome 154 支持响应式 iframe
发布于
Chrome 154 支持按内部文档的固有尺寸(intrinsic size)确定 <iframe> 的一个维度,但嵌入双方都要明确启用。Chrome for Developers 在 2026 年 9 月 16 日介绍了这项功能。外层页面设置 CSS frame-sizing,内部文档设置 responsive-embedded-sizing meta 值;内容变化后,内部文档可以调用 window.requestResize() 请求重新计算
(Chrome 154 响应式 iframe)。
内外文档共同启用
链接到“内外文档共同启用”一节iframe 通常拥有自己的 viewport。当内部文档比该 viewport 高时,frame 可以显示滚动条,而不是 扩展到容纳文档。CSSWG explainer 把响应式 iframe 尺寸描述为一种按内容参与布局的方式,同时保留 同源与跨源 frame 提供的文档隔离。设计要求嵌入 frame 的页面和 frame 内文档分别采取动作 (CSSWG 响应式 iframe explainer)。
嵌入页面在 iframe 元素上应用 frame-sizing。Chrome 的文章列出 auto、content-width、
content-height、content-inline-size 与 content-block-size。auto 保留既有 iframe 尺寸行为;
其他值选择由内部文档提供的物理或逻辑维度,嵌入页面施加在 iframe 上的其他 CSS 约束仍会参与布局
(Chrome 154 响应式 iframe)。
内部文档通过 name 为 responsive-embedded-sizing 的 meta 元素选择加入。MDN 将这个值描述为:
允许文档与 parent 分享自身 layout size,使 frame-sizing 能使用该尺寸。Chrome 的文章还指出,
meta 元素必须在文档加载时已经存在,不能在加载完成后动态插入再激活功能
(MDN,responsive-embedded-sizing)。
这种双重同意把元素控制权与内部文档的许可分开。CSSWG explainer 表示,该设计保留现有内容的 向后兼容性,以及跨源内容既有的隐私与安全保证。没有匹配的双方设置时,既有 iframe 继续采用原有 尺寸行为,而不是向嵌入方暴露内容尺寸 (CSSWG 响应式 iframe explainer)。
内部文档可以限制哪些 parent origin 能收到尺寸。Chrome 示例在 meta 的 content 值中使用
allow-origins=,既可写一个 origin,也可写以空格分隔的多个 origin。文章建议第三方 widget 只列
出确有需要的 origin;通配符允许每个嵌入 origin,显式列表则缩小尺寸披露范围
(Chrome 154 响应式 iframe)。
origin 列表不替代既有嵌入控制。Chrome 把它描述为 CSP frame-ancestors 的补充,后者控制哪些
站点可以嵌入该文档。CSSWG explainer 也讨论了 frame-ancestors:如果恶意嵌入页面能观察跨源
frame 的布局尺寸,这项指令可以限制能够执行观察的嵌入方
(Chrome 154 响应式 iframe)。
初始尺寸与后续变化
链接到“初始尺寸与后续变化”一节初次尺寸交换与文档加载相连。CSSWG explainer 表示,当选择加入的 meta 元素在内部文档的 load
事件发生时已经存在,嵌入页面会收到一个 natural dimension。iframe 的 frame-sizing 值让该尺寸
与嵌入页面提供的其他 HTML 和 CSS 约束共同参与布局
(CSSWG 响应式 iframe explainer)。
浏览器不会持续观察后续布局变化。Chrome 的作者写道,浏览器不会观察内部文档中的每一次 layout 变化。
代码增加内容、展开面板或以其他方式改变布局后,可以在 frame 内调用 window.requestResize(),
请求重新计算尺寸。MDN 也把该方法描述为内部文档改变后用于动态更新的路径
(Chrome 154 响应式 iframe)。
Chrome 建议先完成文档变更,再在 layout 之前调用 requestResize()。文章把显式更新模型与避免
resize loop 联系起来:frame 尺寸改变可能改变内部 viewport,随后改变内容布局,再次改变请求尺寸。
因此,该方法是由应用控制的一次请求,不是跟踪每个 mutation 的通用 observer
(Chrome 154 响应式 iframe)。
CSSWG explainer 记录了初始设计采用一次性尺寸计算的原因。它列出 frame 尺寸变化、CLS、性能成本
与潜在无限布局循环等顾虑,因此在 load 时计算 natural size,而不是自动响应后续所有内容和样式
变化。explainer 的 future extensions 曾把 JavaScript 重新布局请求写作潜在扩展;Chrome 154
交付的功能已经用 requestResize() 承担这个显式角色
(CSSWG 响应式 iframe explainer)。
自动调整 iframe 尺寸对布局的影响
链接到“自动调整 iframe 尺寸对布局的影响”一节嵌入式表单、评论和交互示例可以改变高度,却不属于应用外壳所在的文档。Chrome 的文章表示,旧有
模式需要脚本测量 iframe 内容、用 postMessage() 传递尺寸,再由 parent 更新 iframe。新的协议
把初始尺寸交换放进 CSS 与文档 metadata,同时为后续内容变化保留显式方法
(Chrome 154 响应式 iframe)。
这项变化并没有消除回退尺寸设计。Chrome 文档给出 @supports (frame-sizing: content-height)
模式:feature query 外保留固定高度,支持时再切换到按内容确定尺寸。它还示范了在调用前检测
requestResize。既有 iframe 尺寸代码因而可以继续服务不支持该功能的 user agent
(Chrome 154 响应式 iframe)。
原始报道记录了 Chrome 154 的支持,并链接 Firefox 与 Safari 的开放 bug。MDN 把
responsive-embedded-sizing 标为 experimental 与非 Baseline,理由是部分广泛使用的浏览器不
支持它。这些来源支持渐进增强,却不支持无条件用新属性替换每一种成熟的 iframe 方案
(Chrome 154 中的新功能)。
即使在支持功能的浏览器里,布局稳定性仍是产品问题。Chrome 警告,内部文档晚于 host document 加载时,frame 可能推动周围内容;当响应式 iframe 出现在首个 viewport 时,这可能对 Core Web Vitals 产生负面影响。最大高度或预留空间会改变取舍,但合适约束取决于被嵌入的实际内容 (Chrome 154 响应式 iframe)。
该功能也把职责写得更清楚。嵌入方选择是否让某个 frame 维度来自内容,并保留自己的 CSS 约束; 内部文档选择是否披露尺寸,并可限制合格的 parent origin;frame 内代码选择哪些后续变化值得重新 计算。把三项决定分开,可以避免把 iframe 元素的控制权误当成对内部文档的控制权 (MDN,responsive-embedded-sizing)。
一次渐进式部署可以保留已知高度,在 feature query 内增加 frame-sizing,让选择加入的 meta 在
内部文档加载时就存在,并保护性检测 requestResize()。这个顺序遵循 Chrome 的 progressive
enhancement 示例,让不支持的 user agent 留在原路径,也为团队提供在视觉显著区域启用内容尺寸前
测量布局移动的位置(Chrome 154 响应式 iframe)。
安全审查需要分别覆盖「谁能嵌入」和「谁能收到尺寸」。显式 allow-origins 列表控制后者,
frame-ancestors 控制前者。CSSWG explainer 警告,可观察的跨源尺寸可能泄露 frame 内容信息,
所以需要内部文档主动启用,并限制 origin
(CSSWG 响应式 iframe explainer)。
Chrome 154 带来的实际变化很收敛:支持的 frame 得到一条由双方同意、可显式更新的内容尺寸路径。 它不会让 parent 读取 iframe DOM,不会把后续每次布局变化变成自动通知,也不会消除跨浏览器回退 需求。这些限制让应用可以逐步采用,不必一次重写全部 iframe 方案 (Chrome 154 响应式 iframe)。
站内相关条目
链接到“站内相关条目”一节- Platforms:平台模型与术语。
- Baseline 2026:2026 Baseline 集合。
- By browser:各浏览器的兼容性数据。
待核实
链接到“待核实”一节- Firefox 或 Safari 会在哪些发布版本支持响应式 iframe 尺寸,尚未确认。
- 在形成更广泛互操作性之前,属性、meta 值或方法是否变化,尚未确认。
- 特定 PWA、iframe 与预留空间策略产生多少布局移动,需要测量,尚未确认。
- 第三方 widget 应采用怎样的
allow-origins列表,取决于其部署关系,尚未确认。 - 嵌套响应式 frame 是否会受到更多实现限制,尚未确认。
- 该功能何时能满足 Baseline 条件,尚未确认。
参考来源
链接到“参考来源”一节- Chrome 154 中可自动适应内容的 iframe(bram.us)
- Chrome 154 响应式 iframe(developer.chrome.com)
- 响应式 iframe explainer(github.com)
responsive-embedded-sizingmeta 值(developer.mozilla.org)