Chrome 154 ships responsively-sized iframes with a two-side opt-in
Yuki Tanaka
I wired this into a comment widget this morning and the handshake is exactly what the writeup promised. Chrome 154 gives <iframe> a new CSS property called frame-sizing, and the embedded page has one job: drop a <meta name="responsive-embedded-sizing"> tag in its <head>. The outer page and the embed agree, the frame takes on the size of its content, and nothing has to postMessage a pixel count across the origin boundary. Per Bram's post dated 23 September 2026, only Chromium ships it. Firefox and Safari have no support and no tracking bugs yet.
The two sides of the handshake
frame-sizing goes on the <iframe> and accepts auto, content-height, content-width, plus logical-property variants. That is the embedder's request: size yourself to your content's intrinsic height, width, or both. On its own it does nothing. The embedded page has to opt in with a meta tag:
<meta name="responsive-embedded-sizing" content="allow-origins=*">
The allow-origins value can be a list of origins instead of *, which is how the embed picks who is allowed to receive its size information. If your comment widget is dropped into twenty sites but you only want two of them to auto-size, that is the knob.
The smallest working wire-up
Outer page:
<iframe src="https://comments.example/thread/42"
style="frame-sizing: auto"></iframe>
Inside the embed:
<meta name="responsive-embedded-sizing" content="allow-origins=*">
That is it. No ResizeObserver. No script.
Telling the parent you grew
Content shifts after load. Someone opens a reply, an image finishes decoding, a "load more" runs. When that happens the embedded document calls window.requestResize() and the outer page picks up the new size through the same channel. One method call replaces the postMessage-plus-parseInt-plus-parent-style-write recipe most embeds carry around today.
The cross-browser reality
Here is the part I have to keep honest. Per the browser-support table in Bram's post on 23 September, frame-sizing and responsive-embedded-sizing are Chromium-only right now. Firefox has no support and no tracking bug. Safari has no support and no tracking bug. So this is progressive enhancement in the strictest sense: shipping it today upgrades one engine and leaves the others exactly where they were. If you already keep a postMessage fallback for embed heights, keep it. If you do not, the frame renders at whatever height and width you set on it, same as always.
What I am watching next
Whether Gecko and WebKit file tracking bugs at all, and how allow-origins behaves in the field. A cross-origin size channel is exactly the kind of surface that tightens as embedders test it against ad frames and third-party widgets. I also want to see whether the property picks up more values once authors put pressure on the shape.
Source: bram.us (bram.us)