I don't understand why “expand to fit scrollHeight” hasn't been the default behaviour for <textarea> all along. In a lot of my demos where I want to add this sort of functionality I achieve this effect by somehow running the following 2 lines of JavaScript from the context of an element:

element.style.height = 'inherit'
element.style.height = element.scrollHeight + 'px'

I've written a little JavaScript function that can help me apply an auto-height or auto-width to elements that match CSS selectors here that uses this same logic: https://github.com/tomhodgins/reprocss/blob/master/mixins/auto-expand.js

Mixin Demo: https://tomhodgins.github.io/reprocss/test/auto-expand-mixin.html

Another Auto-Height demo: https://codepen.io/tomhodgins/pen/KgazaE

Another Auto-Width demo: https://codepen.io/tomhodgins/pen/ZpLxjy

As for auto-height <iframe>, I believe I've seen this happen on iOS before, but I'm not sure I could dig up the CSS. I'll see if I can recreate it :D

With iOS, this is their default behaviour for iframes... they call it frame flattening.

What happens when

<style>
  p { font-size: 100px; }
  @media (min-height: 50px) { p { font-size: 1px; } }
</style>
<p>hi</p>

gets iframed into

<style>iframe { height: max-content; }</style>
<iframe src="is-this-a-circular-dependency.html"></iframe>

?

UPDATE: I see this has already been asked and that there are already some proposed answers.

As a website developer, I'd be happy for the iframe to simply increase in size (so the scroll bars weren't required), and to not bother scaling back again.

Which works quite well with the name max-content.

This could be a win for accessibility (and monetization/conversion) for inserted adverts, where e.g. the user has specified a larger minimum text size than the default, but at the expense of page reflows as each ad slot gets populated.

The Working Group just discussed Auto resizing of iframes and textarea based on content size, and agreed to the following resolutions:

• RESOLVED: Add textarea sizing to Sizing L4

The auto-resizing (specifically height) of iframes is a highly desirable feature for authors.

I have been using this feature for quite some time on my event posts, e.g.:

http://tantek.com/2017/305/e1/homebrew-website-club

I use an iframe to embed an unknown number of RSVPs generated by an external service, and it is quite handy (e.g. on iOS Safari) for that iframe of RSVPs to auto-grow (in height) as more RSVPs come in.

I'd very much like to see iframe auto-sizing added to Sizing L4 as well.

@tantek I'm in favor, but that requires addressing the security concerns at the very least; textarea doesn't have that consideration. If we work it out in the same timeframe as the rest of the features and get implementer backing, I'd be happy to have it in L4.

I vote for max-content for <textarea/> and other elements but against for not sameorigin <iframe/> and <object/>. If <iframe/> is not sameorigin, the value should be resolved to auto.

Reason: the autosizing of textarea should be implemented, and also horizontal equivalent for width for <input/> but without security problems.

BTW. <iframe/> is old technology and this attribute doesn't have to be implemented on it.

Moving textarea and input discussion to #2141 ; this one will remain open for iframe, since its security implications are more complex.

Note: The CSSWG resolved to accept this for textarea and text input fields in #2141.

In the case of the iframe, the child page would need to send a HTTP header (e.g. Expose-Height-Cross-Origin: 1), so it does not leak information about that website

From whatwg/html#555:

For cross-origin I suppose the embeddee would need to opt-in somehow (e.g. meta tag), to not expose new information cross-origin.

Now that we have Feature Policy, I think that's the way to go about that. Similarly, there is a proposal to expose bounds cross-origin.

Since an <iframe> src can be set to an SVG, would max-content work for SVGs as well?

This is actually great that something might actually happen, because it means we could finally:

1. Have HTML partials!
2. Emulate container queries!

Could it be implemented for same-origin iframes please even if not all security concerns are sorted out for the foreign-origin scenario yet?

What I'd be interested in seeing here is a more formal description as "contents" isn't really cutting it I think. It's effectively about resizing the viewport to some dimension and that definition will need to account for negative margins and other fun tricks.

@jensimmons Because you had strong concerns against this. Let me note again that there are use cases besides the ad frameworks one.

The company I work for has different websites based on different server software stacks. Though all of them share specific widgets on special occasions. These widgets are surved from a general internal domain and embedded via iframes. We are currently using the postMessage() method mentioned by several people here in this thread for resizing the iframes to avoid the scrollbars to be shown.

So therefore I'd also welcome this feature. Regarding security, as discussed already, it needs to be ensured that both sides express trust in each other.

Sebastian

Here's a popular example, to support my point that I think it would overall increase security of the web to make this possible:

GitHub recommends embedded Gists into other websites using a <script> tag.

If we look at what that script does, e.g. https://gist.github.com/olafurpg/94e0e735ceda0a355fa7e226c1431466.js, we see that all it does is use document.write() to add a CSS styleheet and output HTML with the Gist.
There is no reason this would have to need a <script> tag, other than that if embedding worked through an <iframe>, there would be no easy way for GitHub to resize it based on the Gist size (not without telling embedders to add JS to their page that communicates through postMessage(), which is too much to ask for). So instead, they go with a simple <script> tag.

What does this mean for security? That script can execute any JS in the context of the page and has full control of the DOM. Gists are user content, and that user content is escaped by the GitHub backend and put into the string passed to document.write(). If there is any bug in that escaping logic, a malicious user could craft a Gist that doesn't escape properly and injects arbitrary JS into any page embedding the Gist. And if you get access to someone's GitHub account, you can change Gists that are already embedded somewhere (e.g. it's the most common method to embed code snippets in Medium blog posts).

I think this is a huge security flaw "forced" by the shortcomings of the platform atm.

Now imagine if GitHub could simply use <iframe>s. They would be sandboxed and the JS could get compromised as much as you want - it could never affect the parent page (besides growing in size, which is easy to control with CSS from the outside, even with a style tag on the snippet that GitHub would recommend).

Regarding "use cases" - Consider all 3rd party content, like user comments (disqus), videos, maps, tweets, facebook feeds, calendars, gists, ads, etc... it would be much safer if they were in an <iframe>, using their own isolated process (ref spectre), and did not involve the host website including an unsafe/dangerous 3rd party <script> (which grants far too much access).

I should also note that before Safari 13 on iOS, iframes were re-sized automatically (to avoid the scroll bar), with none of these security considerations.

Heya, @chrishtr asked me to take a look at the proposal here to give my thoughts. Based on #1771 (comment) and some subsequent ones here is what comes to mind:

• Using resizeTo(), instead of e.g. a HTTP header, is a nice trick and should make this more usable for people.

• It seems like there are two opt-ins on the outer side: first, you have to set allow="resize", and second, you have to actually use the from-element keyword. I don't know if we need both of these. I would probably cut the allow="resize" since the CSS from-element seems nice and versatile.

• The dance where the parent is allowed to cancel the event seems potentially tricky to implement and could cause slowness, for out-of-process iframes. You would need to send an IPC to the parent frame to fire the resize event, which would then send an IPC to the child frame telling it the result, before any resizing actually happens. It seems doable, but maybe worth considering whether or not running a full JS function here is really needed. The alternative is basically trusting any iframe that you set contain-intrinsic-size: from-element on, plus you could impose declarative constraints (e.g. max-width/max-height).

• However, I'll note that window.resizeTo() is already async (test). So there's at least some precedent for resizes not taking effect synchronously. It just might be bad for users if resizes are slower than they need to be.

• +1 to the promise return value not making too much sense, because the resize only had an effect if the outer page uses from-element.

• This whole feature needs to not work for situations like fenced frames or portals where we also censor postMessage(). That seems fine.

• I would not auto-inject into srcdoc; that seems strange.

• +1 for strong event loop/ResizeObserver integration at the spec level. I don't think this should be too hard.

• I can't quite tell from the minutes but it seemed like people might be saying there's precedent for not requiring an embedee opt-in, and thus we should consider not requiring it for this feature? That'd be a very bad cross-origin information leak so please don't do that.

I hope this helps, and would look forward to working on this feature with you all!

It's been briefly mentioned earlier in the thread, but being able to support this without any scripting at all would also be great. It would allow treating an iframe as if it were just an ordinary block element in the page, complete with dynamic resizing just based on CSS alone. In theory it could also perform better as no JavaScript handshake would be necessary.

In fact, since JavaScript can already resize a page as desired, I'm not sure why separate new communication methods are needed if a scriptless method is available: the page in the iframe could just resize itself and the parent would not need to differentiate between a resize caused by CSS only or a resize caused by JavaScript.

I think the talk of using a header to opt-in from the embedee side was specifically intended to support the noscript scenario.

@LB--

It's been briefly mentioned earlier in the thread, but being able to support this without any scripting at all would also be great.

This would be ideal -- if an iframe could be treated like a type of inline block content that just resizes based on vertical (and/or horizontal?) overflow (and depending on whatever security measures are needed to whitelist the iframe). A script could therefore just change the CSS property to set resizing behavior.

Hi folks,

@tabatkins, @chrishtr, and I spent some time working on this offline. We ended up with the explainer at https://github.com/domenic/cooperatively-sized-iframes . Summary:

<iframe style="contain-intrinsic-size: from-element 500px 500px"
        src="iframe.html"></iframe>

<!-- In iframe.html --->
<html requestedwidth="480" requestedheight="320">

We did manage to come up with a solution that doesn't require JavaScript in the simplest cases, where the iframe knows specific pixel values for the width and height it requests. But for dynamic resize-to-content, it's quite tricky, as discussed in our section "But what about auto-resizing?". (The basic problem is how it can cause infinite resize loops.) So the initial proposal would require JavaScript to hook up a ResizeObserver or similar and manipulate document.documentElement.requestedWidth and requestedHeight, like in this example.

Feedback is welcome, either on that repository if you want to have a more focused discussion on individual aspects of the proposal, or here if you'd prefer that.

Agenda+ to propose adding the from-element syntax and requestedwidth/requestedheight attributes.

Notes on from-element:

• It should (of course) apply to iframes
• Should it apply to object and embed? SVG embedded in these already have an intrinsic sizing capability similar to the proposed iframe thing.
• Should it apply to other replaced types such as image and video?

I would propose it applies to all replaced elements which have a communicated intrinsic sizing, but I may be missing cases where this is not desirable.

Notes on requestedwidth / requsetedheight:

• As noted in the explainer, this could also be a CSS property, or even a javascript method. We could discuss tradeoffs.

it's easy for this to cause infinite resize loops, where the changing viewport size causes an changing requested size, which causes a changing viewport size, etc.

Can we apply a few iterations of resizing until the size 'settles'? And if it doesn't settle, log an error to help developers debug and give up until the next window resize event?

I like the use of attributes, so the width/height can be provided to the iframe as soon as the HTML is received... out of interest, would there be any benefit to using a single attribute, like requestedsize="300 400", in the same way that the srcset attribute contains multiple values (maybe string parsing would be an unnecessary complication, and future values like "300 auto-on-load" might be a bit weird)?

I like the auto-on-load suggestion, and I'm happy to wait for that to be introduced in the future (this proposal would help the main issue today, to include 3rd party content, which nearly always uses JS anyway; delaying that for everyone to agree on how an auto value should work, probably isn't a good idea).

Thank you for writing this up, and providing examples to show how it can be used.

I don't think we should add these to embed and object. Those elements are poorly defined at the moment and we need to change how they work to address various leaks. Adding more complexity to them does not seem warranted.

maybe string parsing would be an unnecessary complication, and future values like "300 auto-on-load" might be a bit weird

That was my instinct, plus the fact that most of the precedents in HTML are to use separate attributes.

I don't think we should add these to embed and object

I agree with this in general, although @chrishtr pointed out that SVG-in-<object> has auto-sizing behavior already, which makes this worth thinking about.

The way that sizing works is not interoperable and has some cross-origin leakage problems, in particular if you navigate the <object> element to and from SVG resources. (See https://bugzilla.mozilla.org/show_bug.cgi?id=1594986; whatwg/html#7037 is also relevant here. whatwg/fetch might also have some relevant discussion in a PR somewhere.)

The CSS Working Group just discussed [css-sizing] Auto-resize iframes based on content, and agreed to the following:

• RESOLVED: Use HTML mechanism (either attributes or meta) to express the intrinsic size of the child
• RESOLVED: Add `contain-intrinsic-size: from-element` with a note that it needs further discussion on the name

I'd love to see this being picked up again. A <iframe srcdoc=... fit-contents> element would be a great way to isolate web components. All the code run in srcdoc would point to the right document, so I don't have to ask every library/tool I use to "use element.shadowRoot instead of globalThis.document"