Open tabatkins opened 7 years ago
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 https://github.com/w3c/csswg-drafts/issues/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 https://github.com/whatwg/html/issues/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:
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 srcdoc
s 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?
I am a bit confused why the security concern is a blocker for <iframe>
, when <object>
already does this (at least when embedding an SVG, even cross-origin). <iframe>
s are a lot more secure because they have attributes like sandbox
and csp
, which <object>
does not. So currently we are forced to use <object>
to embed SVGs in a responsive, accessible, interactive way (<img>
doesn't expose contents to screen readers, make links clickable or text selectable) with no way to disallow scripts in SVG to run. Having iframe resizing would therefor be an improvement to security in my eyes because it stops forcing us to use less secure alternatives.
Been discussing this with @chrishtr as an idea to revive.
The killer problem with iframe resizing is that the intrinsic size of a third-party page can be an important/dangerous information channel on its own, so allowing sites to get this effect on arbitrary third-party sites is out of the question. A less obvious issue is the reverse; if an iframe can unexpectedly control its own size, it can be used to attack the framing page.
The trick, then, is making sure that this is opt-in on both sides.
window.resizeTo()
function, which currently is a no-op in an iframe, to instead fire a "resize" event on the iframe in the containing document (bubbling, cancelable) when resizing is allowed.allow
attribute, allow=resize
. If this is not set, the "resize" event will never show up.preventDefault()
the event, in which case nothing happens.from-element
keyword on contain-intrinsic-size
. Like the existing c-i-s: auto
, you can accompany this with a default size which'll be used before it's set, like contain-intrinsic-size: from-element 400px 500px;
.In total, then, the containing page doesn't need to run any script at all if they trust the framed page; they can just write <iframe allow=resize style="contain-intrinsic-size: from-element 500px 500px">
and be done. The iframe will start out with a 500x500 intrinsic size (rather than 300x150, the default), and if the iframe'd document calls window.resizeTo()
, the iframe will automatically switch its intrinsic size to that value.
However, if the outer page does want to control things (inspecting the value before approving it, batching resizes until later, etc) it's trivial to just listen for the event and preventDefault()
when it needs to delay something. The iframe'd page can tell when its been resized by listening for the "resize" event on its own window, as normal.
(contain-intrinsic-size
is used here because, effectively, iframes are always size-contained (the requirement for c-i-s
to apply), and c-i-s
lets you hijack the intrinsic size of the element, which is the right place for this size to be inserted into the layout model. It also lets you provide a default, which is useful on its own.)
The above proposal does require the iframe'd page to run some script, and if it wants its size to be content-based, to do measurement on its own, possibly polling if the size might change over time or due to user interaction. This is because even in a fairly trusted situation, directly exposing content-based sizes can still be dangerous for both sides.
However, in a same-origin environment, we can generally loosen these restrictions and assume trustworthiness, so we can do proper content-based resizing and just need to make sure that it's opt-in so we don't get a behavior change on existing pages. So, the proposal for same-origin iframes is:
allow=resize
and contain-intrinsic-size: from-element
to signal that the outer page wants the iframe to be resizable.intrinsic-size: auto | <<length>>{1,2};
, with auto
meaning the laid-out size of the root element. The c-i-s: from-element
value automatically updates to match what this property dictates.So, how does this proposal sound? Agenda+ to intro it at the next call (no need for decision yet).
Is there precedent for this in libraries/frameworks/userland? It seems you could already do this with postMessage()
if you wanted to.
Is there precedent for this in libraries/frameworks/userland?
There are indeed various libraries that do it. Here are some examples / related links:
https://stackoverflow.com/questions/153152/resizing-an-iframe-based-on-content http://blog.apps.npr.org/pym.js/ https://github.com/whatwg/html/issues/555 (contains more links to libraries implementing the functionality). The Disqus team also asked for it way back when.
I think this is a very common situation also in ads, where the creative may change its sizing and request adjustment in the parent page.
Those comments are also asking for automatic resizing without script in some cases, based on the intrinsic sizing of the iframe content.
It seems you could already do this with
postMessage()
if you wanted to.
Yes you can, and developers do it. The reason I think this should be a built-in API are:
Yeah, the first solution is basically "standardize and simplify the postMessage() dance".
The second solution is trying to solve the original <iframe seamless>
use-cases (safely embed arbitrary content in your webpage, via a locked-down iframe+srcdoc) without the complications of the "apply outer page's style to the iframe'd page" that seamless
tried to do; it's slightly more complex than strictly necessary to keep the overall solution consistent with the first one.
Looking at this again it struck me there's no success/failure indication for the caller of window.resizeTo()
. Not sure if we can return a promise there that resolves with the new/unchanged dimensions, but that would probably be desirable I suspect.
<html>
(and <head>
, <title>
, <body>
) is optional in srcdoc
content, which means that it is implied, if I understand correctly. Please make whatever property is necessary as opt-in in same-origin contained frames also implied for srcdoc
content. Otherwise srcdoc
s would have to be much more verbose than desired for this to work.
I like the suggestion, and I'm fine with the iframed page having to use JS. My focus is on making it as safe and easy for the parent page to include 3rd party content (e.g. no 3rd party <script>
getting access to the rest of the page/site, also helping with site-isolation; or the site itself having their own JS to handle a non-standard postMessage()
).
The bit I'm not completely sure on is sizing. I like how you've thought about providing a default size while the content is loading (like how an <img>
can now use width/height attributes for the aspect-ratio
). But I wonder if there's a simpler way (without using JS) for the parent to apply limits to the size of the iframe?
Most cases I can think of will only want the height to change (the parent pages design tends to define the width). So maybe the CSS (min-|max-)?(width|height)
might be relevant here?
For example, width: 100%
or width: 30em
could be used by the parent page to fix the width?
Also, do you consider the use of contain-intrinsic-size: from-element X Y
to be required, considering allow=resize
is granting permission to change the size? or is it just providing the default size?
Personally I'm not fine with JS being required to use JS to resize. Requiring JS for resizing is counter to spreading the use of sandbox
and csp
attributes when embedding static content, which improve security by disallowing JS.
E.g. it should not be required to add JS to an SVG or a static HTML endpoint just so it can embedded in a secure and accessible way (that would make it not well portable as a file). And requiring JS would make it less secure, because I'd love to be able to use sandbox
or csp
to disallow any JS in the iframe
, but that of course is not possible then.
@felixfbecker, with @tabatkins suggestion, a same-origin iframe won't require JS (good for your own sandboxed content). 3rd party content (from a different origin), that's going to be trickier to enforce (most 3rd parties will want JS), and should be less of an issue as different origins get their own process/renderer (ref Post-Spectre Web Development and "out-of-process iframes").
good for your own sandboxed content
A lot of times my own sandboxed content will be on a different origin; it is on a different origin specifically to help with the sandboxing. I'm not sure how much need there is for optimizing the same-origin case; it might even be a bad idea, if it encourages people to host their untrusted content in the same origin.
Please make whatever property is necessary as opt-in in same-origin contained frames also implied for srcdoc content.
You don't need to have an html
tag in the code to set a property on it; dropping a <style>html { intrinsic-size: auto; }</style>
into the srcdoc string suffices, since the html
element gets auto-created by the HTML parser.
Looking at this again it struck me there's no success/failure indication for the caller of window.resizeTo(). Not sure if we can return a promise there that resolves with the new/unchanged dimensions, but that would probably be desirable I suspect.
It currently returns undefined
, so there's a decent chance it's upgradeable, actually.
However, I'm not certain that it would be useful vs just listening for "resize" on their own window. Fulfilling the promise when the event isn't canceled doesn't tell the iframe that it's been resized, it just indicates that its "from-element intrinsic size" has been updated; whether or not this actually results in a size change for the iframe depends on the containing page's layout. Similarly, rejecting it when the event is preventDefault()'d doesn't tell the iframe that it won't be resized, just that its "from-element intrinsic size" isn't going to be updated. I just can't think of anything that an iframe'd page can meaningfully do in response to this, regardless of whether it's fulfilled or rejected.
On the other hand, the "resize" event on window
gives you actionable information at all times, regardless of how the resizing took place.
Most cases I can think of will only want the height to change (the parent pages design tends to define the width). So maybe the CSS (min-|max-)?(width|height) might be relevant here?
Yeah, since this would only affect the "intrinsic size" of the iframe, which is a very weak size input into the layout algorithms, almost anything the author in the outer page does will override and let them have whatever level of control over sizing they wish.
Also, do you consider the use of contain-intrinsic-size: from-element X Y to be required, considering allow=resize is granting permission to change the size? or is it just providing the default size?
Not strictly required, but without it, it's not clear what the intrinsic size should be before the first resizeTo()
call. We could assume 300x150 (the current default), I suppose, but that's probably rarely a useful starting size anyway?
I think requiring it also plays slightly better into the generalized feature, where I want to allow textarea
to resize based on its content; making the feature consistently activate with a particular property invocation might make it easier to learn and remember, rather than some elements having special ways of triggering the same behavior.
I could probably be convinced otherwise, tho.
You don't need to have an
html
tag in the code to set a property on it; dropping a<style>html { intrinsic-size: auto; }</style>
into the srcdoc string suffices, since thehtml
element gets auto-created by the HTML parser.
Ah, good.
Is there a reason why a srcdoc
should have to explictly opt-in though? The person or script which generates the containing document has also full control over the srcdoc, since it is a part of the containing document. Having to opt-in from inside the srcdoc and from outside seems redundant in this case.
@tabatkins Thanks for the background on intrinsic size, that really makes sense.
I think a default contain-intrinsic-size
would be useful, only because 3rd party services could say "You can include our thing safely on your website with":
<iframe src="https://..." allow="resize"></iframe>
I'd rather not see them adding (unsafe-)inline styles to their example/template, or making assumptions on what would be appropriate for the page it will appear on. Maybe browsers could use iframe[allow~=resize] { contain-intrinsic-size: from-element 300px 150px; }
in their default style sheet, so developers would see it in their dev-tools, find out what it does, and/or hopefully notice they are getting a weird resize/reflow on page load, and copy/customise it for their website (while the remove the border, set a width, and maybe a max-height).
And yes, they would need it for a <textarea>
(I like this suggestion as well), but I suspect many developers would be doing a copy/paste/tweak, rather than learning/remembering.
Yeah, I suppose having it set in the UA stylesheet on resizable iframes would work fine; there's already sufficient indication of intent from the attribute, after all. And that way, the style is observable from the DevTools, so it's not too hard to see what you need to change to modify the behavior yourself.
Is there a reason why a srcdoc should have to explictly opt-in though? The person or script which generates the containing document has also full control over the srcdoc, since it is a part of the containing document. Having to opt-in from inside the srcdoc and from outside seems redundant in this case.
It's a little magic, which I'm always wary of, but srcdoc is explicitly designed for usability, so it might be okay to auto-inject that style into a srcdoc'd iframe at the UA level (so the srcdoc document could easily override it necessary).
A lot of times my own sandboxed content will be on a different origin; it is on a different origin specifically to help with the sandboxing. I'm not sure how much need there is for optimizing the same-origin case; it might even be a bad idea, if it encourages people to host their untrusted content in the same origin.
A fair concern, but I think the risk of people doing the fairly-obviously-harmful thing of putting untrusted content on unsandboxed same-origin is worth the benefit to authors of allowing resizing to work for same-origin or srcdoc content without script being required. It's not like it's a single line of script, either; you need to regularly poll for changes to your content size.
Rather than minting a new property intrinsic-size
that's only useful for this case and is set on the root, can we re-use the standard sizing properties? Like if the root of the contained page says max-content
, then we pass up its max-content size. And if it says 500px
then we pass up 500px. I doubt there's many pages setting sizes on the HTML element, and of those that are, I imagine few would be disturbed by being put in an iframe of their chosen size.
Yeah, that might be reasonable.
The CSS Working Group just discussed [css-sizing] Auto-resize iframes based on content
.
@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 https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-805117925 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
:
object
and embed
? SVG embedded in these already have an intrinsic sizing capability similar to the proposed iframe thing.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
:
In https://lists.w3.org/Archives/Public/www-style/2017Aug/0045.html, Craig Francis said:
Just re-raising the suggestion of allowing an iframe or textarea to increase its height based on its content.
Mats Palmgren suggested that I raise this issue again, as Firefox is unlikely to implement it unless the CSSWG agrees to spec it.
For iframes, this feature would allow easy and secure (isolated) embedding of third party content without issues relating to scroll bars (i.e. needing custom JavaScript to ask the parent page, via postMessage, to change the iframe height).
For textrareas, this is just a convenience feature, as trying to get JavaScript to do this is tricky (e.g. the browser can automatically add/remove scroll bars, which can throw off the calculations).
When we discussed this last time (after the @seamless attribute on the
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 (e.g. if the user is logged in).
PS: This has been discussed in a number of times before, the earliest one I've found is 16 years old:
https://bugzilla.mozilla.org/show_bug.cgi?id=80713
And I've written up some notes about this feature, which includes the suggestion of using it for element height animation (e.g. disclosure widgets):
https://github.com/craigfrancis/iframe-height