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!

I don't buy the security argument, who cares if someone knows that you are logged in somewhere? When couldn't you infer the same information using timing attacks to see if a resource has been cached? And any half-competent sysadmin worried about that kind of leak should be blocking frame embedding entirely.

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.

When an <iframe> is created at the moment, it will typically create a scrollbar (the thing I want to avoid). I assume the browser knows how big the "content" is to make that scroll bar; so can we use that to set the height?

I'm fairly sure we can treat the width as fixed, as we do with the main browser window - where it will wrap the contents, or use a horizontal scroll bar when that's not possible (I think most developers will understand if they try to show something that's too wide).

Yeah, I'm not really sure where all that machinery is defined and what defines that overflow to the left on ltr pages is ignored, etc. There is probably something there that can be used, but then there's also the complication of defining this in a way that works for mobile, where there's multiple viewports and such.

Just a note on why this would be useful, even if only for same-origin iframes in the beginning: With Edge soon using chromium, all major browsers will support <iframe srcdoc>, and srcdocs are always same-origin.

Encapsulating comments in a blog is a use case for <iframe srcdoc> which is also given as the example in the HTML standard. Comments are almost always displayed in full height in blogs, so having the <iframe> as high as its content is almost always the desired behaviour.

@emilio the proposal for recursion appears to be to do an initial pass and then let the scrollbars appear as needed: https://github.com/craigfrancis/iframe-height/blob/master/problems/infinite-loops.md.

So if you do layout during page load, then you get an empty iframe? What Roc implemented in Gecko was that media queries were resolved against the parent document.

@emilio, I'll be very happy if you can improve on this... my suggestion it just there to make the most basic implementation that should work for both browser and website developers (I have since updated that page to note a suggestion where the child page could call a JavaScript method to request the height be updated, but that's just to round off the idea).

Maybe my tone was harsh (sorry) but I am confused about the downvotes with regard to my comment on side channels.

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

I think relaxing the header policy for same origin and subdomains would be reasonable.

At the very least, allow this to be set using <meta> tags.

Side-channels are indeed real and problematic and therefore we should strive not to introduce more of them. The primary security boundary of the web is origins and therefore subdomains are not that reasonable as you might think.

Side-channels are indeed real and problematic and therefore we should strive not to introduce more of them.

I'm sorry, I understand wanting to err on the safe side. A lot of "technically less secure" arguments make implementation and uptake harder without materially impacting security. I was also just interested in what serious attack would be 😸.

Ergonomics is my main concern, which can be addressed by making this feature controllable via HTTP headers and <meta> tags. Would a global JS variable be reasonable?