Opened 11 days ago
Last modified 10 days ago
#66289 new enhancement
Explore use of responsive iframes for embeds
| Reported by: | westonruter | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | Embeds | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: | performance |
Description
Chromium (Chrome and Edge) has implemented support for responsive iframes, allowing an iframe to automatically resize based on its content without the need for any JavaScript on the host page to resize it via postMessage. This is something we should explore supporting in WordPress, both for WordPress post embeds and for other third-party embeds.
See:
Attachments (1)
Change History (3)
#2
@
10 days ago
One problem I ran into while testing: mixed versions.
If the host adds frame-sizing: content-height; height: auto but the embedded site doesn't print the meta tag, the iframe falls back to the default 150px and the card gets cut off. That covers every site on current WP, and also other discovered oEmbed providers, since their iframes get .wp-embedded-content too (embed.php). The host can't tell from CSS alone whether the embedded page opted in.
So it seems like it'd need some JS anyway, e.g. the embed template telling the host over the existing postMessage channel that it supports responsive sizing, and only then switching that iframe to height: auto. postMessage also has to stay for revealing the iframe (embed.js) and link clicks (embed.js).
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)

I was curious how this would fit with the current post embed setup, so I tried it in Chrome 155 with a cross-origin host page, using embed markup generated by wp_filter_oembed_result() and the current wp-embed.js.
What I found:
sandbox="allow-scripts"iframes, so the opaque origin doesn't seem to be a problem.content="allow-origins=..."value. A bare<meta name="responsive-embedded-sizing">did nothing in my tests, same-origin or cross-origin.frame-sizingseems to need the iframe's height to beauto. Theheightattribute we print (embed.php), a CSS height, and wp-embed.js settingiframe.height(embed.js) each overrode it. So the host would needheight: autoon the iframe.min-height/max-heightare respected, so the current 200–1000px bounds could move to CSS.window.requestResize(). Without it, it kept its first height. I tested this with a DOM change, not an image load, but the featured image case (embed-template.js) would presumably need the same.