Feature request: Allow auto-resize on iframe

I’m making the suggestion here as well, as requested by Alan Cutter.

After the recent removal of the @seamless attribute on the <iframe> from the WHATWG spec (issue 331); we still need to consider the problem of setting the height of iframes, so they contain their content without scroll bars.

The full justification is at:

The discussion started on the W3C WWW-Style mailing list:

https://lists.w3.org/Archives/Public/www-style/2016Jan/0236.html

But this pretty much died out last month when Ojan Vafai insisted that the ResizeObserver was a solution to this problem (I don’t think it is):

https://lists.w3.org/Archives/Public/www-style/2016Mar/0198.html

So ignoring the Chrome developers, we have Simon Fraser from Safari, and Robert O’Callahan from Firefox, who say that this is possible to implement (Safari having already done this for their “frame flattening” feature).

I have written up some notes about the infinite loops problem, which should be rare if we only allow the the height to change. And if it really does become an issue, we can cheat, and let the browser do an initial layout, and if it determines a second pass is necessary, then lock the height, and use scroll bars as we do today.

And as an aside, if height: max-content was implemented on iframes, this would also be useful for texareas:

Feature request: Auto-resize textarea

And with height animation:

Feature request: Animating max-height / height based on content

Isn’t this a job for the overflow or overflow-y property?

The iframe has traditionally not been using overflow, so I believe this migh have backwards compatibility issues.

For more info, the original suggestion to add a new keyword came from Tab Atkins Jr on:

https://lists.w3.org/Archives/Public/www-style/2016Jan/0242.html

Yeah, this is not an overflow issue; we’re not trying to deal with the content that overflows the iframe, but rather make the iframe size to not have its contents overflow.

I think this would be huge. With HTTP/2, this could be the end of global CSS as we know it; but it might be nice to somehow pierce into iframes with variables or similar.

Hi @Tigt, personally I think this would (with a couple of other changes) allow most third party content to be put inside safe iframes, and not be given full access to a page with a <script> tag, so likewise I think this could be huge.

As to CSS being passed into the iframe, this is kind of what the seamless attribute tried to do (ish), and that was removed from the spec fairly recently, as no browser implemented it - so I’d be tempted to just push for this bit to be done first (a fairly common feature request, some going back to 2001 and 2005), then we can follow up later with additional requests (maybe some new attributes could be added to pass information into the child frame, or be passed in the URLs query string?)

Oh yeah, the full-blown style sharing of seamless is something to avoid. I was thinking some sort of opt-in styling, like passing values to variables via :root or similar.

We can kind of fake it today using the URL hash and :target, or media queries and odd width values, so that should be enough to tide us over for the basic implementation.

I should have followed up yesterday, as you have a really good point Taylor.

I must confess I stole your idea when talking to Chris Palmer about using iframes for advertising (where some advertisers need to know about the content of the parent page)…

https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0083.html