#1223: Other Spec Review: Responsively-sized iframes

Visit on Github

Opened Apr 27, 2026

Specification

https://drafts.csswg.org/css-sizing-4/#responsive-iframes

Explainer

https://github.com/w3c/csswg-drafts/blob/main/css-sizing-4/responsive-iframes-explainer.md

Links

The specification

Where and by whom is the work is being done?

  • GitHub repo: https://github.com/kojiishi/csswg-drafts
  • Primary contacts:
    • @kojiishi, Google, Chromium implementer
    • @bfgeek, Google, Chromium implementer
    • @chrishtr, Google, Chromium implementer
    • @tabatkins, Google, spec editor
    • @atanassov, Microsoft, CSS WG chair
    • @astearns, Adobe, CSS WG chair
  • Organization/project driving the specification:
  • This work is being funded by:
  • Primary standards group developing this feature: CSS WG
  • Group intended to standardize this work: CSS WG
  • Incubation and standards groups that have discussed the design:

Feedback so far

You should also know that...

No response

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1223

Discussions

Log in to see TAG-private discussions.

Discussed Jun 1, 2026 (See Github)

Dan: I have one main concern: this is a two-way opt-in. The embedding site lights up the feature for iframe, and the iframe has a one-bit opt-in--a meta tag that they include. The embedee does not make any decision about who they enable it for. Multiple embeddees can pull in an embedder if they don't set their CSP properly. I'm not the only one to rasie thise concern, so we can "plus one" the existing critique. I want to be more constructive, though. Should the op-tin be CPS, similar to frame ancestors? I don't know that I have enough of a feel for all of the CSPs to know if that's an appropriate use. If anyone has thoughts on that, I would love input.

Jeffrey: CSP is very complicated, and I'm reluctant to say "please add more stuff to it". Maybe we stick the list of domains in this meta tag. Or we say, "find a way to put this info next to each other."

Dan: I can draft a response along those lines. I'll check with Esahn before I post.

Discussed Jun 8, 2026 (See Github)

Dan: Discussed with Essan, we will maybe try to work on it asynchronously more Lola: I saw that Luke and he discussed it a bit today..

Discussed Jun 22, 2026 (See Github)

Dan: Will reach out to @toreini to determine what the mutual position is

Discussed Jun 29, 2026 (See Github)

(Skipped.)

Discussed Jul 6, 2026 (See Github)

Dan: I think I understand the point Ehsan was making in the proposal. I have drafted a comment and encourage people to review it.

Luke: I might have a different take. I think the CFP is enough. I think the securitiy model is acceptable.

Christian: Dan, do you want to edit the proposed comment?

Dan: It would be helpful if we could be on a call with Ehsan to discuss. Will take this to Slack.

Comment by @dandclark Jul 14, 2026 (See Github)

Since it looks like fenced frames will be sticking around in Chrome per https://privacysandbox.google.com/overview/status it would be good if the explainer could elaborate a bit more on why they're excluded. Presumably this is in line with <fencedframe>'s design goal of limiting communication between the embedder and embedee, but it'd be good for the explainer to call this out as something that needs to be a permanent exclusion rather than something that might be implemented later.