New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-sizing] Auto-resize iframes based on content #1771

Open
tabatkins opened this Issue Aug 31, 2017 · 12 comments

Comments

Projects
None yet
@tabatkins
Member

tabatkins commented Aug 31, 2017

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 <iframe> was removed from the WHATWG spec), it was suggested that we used:

iframe,
textrarea {
    height: max-content;
}

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

@tomhodgins

This comment has been minimized.

Show comment
Hide comment
@tomhodgins

tomhodgins Aug 31, 2017

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

tomhodgins commented Aug 31, 2017

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

@craigfrancis

This comment has been minimized.

Show comment
Hide comment
@craigfrancis

craigfrancis Aug 31, 2017

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

craigfrancis commented Aug 31, 2017

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

@eeeps

This comment has been minimized.

Show comment
Hide comment
@eeeps

eeeps Aug 31, 2017

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.

eeeps commented Aug 31, 2017

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.

@craigfrancis

This comment has been minimized.

Show comment
Hide comment
@craigfrancis

craigfrancis Aug 31, 2017

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.

craigfrancis commented Aug 31, 2017

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.

@liamquin

This comment has been minimized.

Show comment
Hide comment
@liamquin

liamquin Aug 31, 2017

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.

liamquin commented Aug 31, 2017

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.

@astearns astearns removed the Agenda+ F2F label Nov 6, 2017

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Nov 6, 2017

Member

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 full IRC log of that discussion <gregwhitworth> Topic: Auto resizing of iframes and textarea based on content size
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1771
<gregwhitworth> TabAtkins: there have been many requests for textarea and iframes resize on content
<gregwhitworth> TabAtkins: we talked it over and thought, yeah probably ok
<gregwhitworth> TabAtkins: we started experimenting with this
<gregwhitworth> TabAtkins: figure our some mechanism content based sizing for textarea and iframes
<gregwhitworth> TabAtkins: we learned some issues impl seamless with iframes due to COR leaking information
<gregwhitworth> TabAtkins: we suspect we'd walk up the frame tree until we hit a fixed size to resolve the mqs
<gregwhitworth> TabAtkins: Someone from Moz impl this
<gregwhitworth> dbaron: we got the spec to say that's how media queries work, but seamless was removed
<gregwhitworth> dbaron: we have code for it - but it's not necessarily something you can write up in a spec
<gregwhitworth> dbaron: you need to figure out how to spec it
<gregwhitworth> iank_: what type of interesting things
<gregwhitworth> dbaron: I'd need to look, like it tries to do layout
<fantasai> s/do layout/do layout, and then tries again/
<gregwhitworth> rossen: we used to have a technology that would allow you to do layout based on then content size and we killed it
<smfr> q+
<gregwhitworth> Rossen: performance becomes a concern for those
<tantek> The iframe use-case for me is known width (set by container), auto (preferably auto-expanding) height
<gregwhitworth> Rossen: when you consider extensions they try to size the box, and it's shrink to fit it becomes very bad for perf
<gregwhitworth> Rossen: Our experimentation for this suggests it was bad, but maybe you'll find something
<gregwhitworth> TabAtkins: they're both pretty separate features anyways
<Rossen> q?
<gregwhitworth> TabAtkins: are we ok experimenting in this space
<gregwhitworth> TabAtkins: the textarea would go into sizing 4
<gregwhitworth> smfr: we've had the auto sizing of the iframe even COR
<gregwhitworth> smfr: it makes your frame layout outside in rather than inside out
<gregwhitworth> smfr: we've had quite a few media query bugs
<gregwhitworth> smfr: we ran into media query cycles
<gregwhitworth> TabAtkins: that means that you weren't doing media queries the way we defined
<smfr> q-
<gregwhitworth> smfr: it does bring about nasty things in the code
<gregwhitworth> TabAtkins: how is this different from regular layout
<gregwhitworth> smfr: you can avoid laying out the iframe, if you have to you have to dirty the other nodes
<gregwhitworth> TabAtkins: ok, let's talk about this later
<gregwhitworth> dbaron: I think the media query problems you had were due to doing what authors weren't expecting
<gregwhitworth> TabAtkins: this would be opt in
<gregwhitworth> tantek: how do you trigger behavior in iOS
<gregwhitworth> smfr: you always get it
<gregwhitworth> smfr: users don't experience nested scrollers, we always wanted page scrolling to win so you don't get trapped
<gregwhitworth> tantek: width is expected and height is auto
<gregwhitworth> smfr: yes
<gregwhitworth> Rossen: ok, so - it seems that Google wants to experiment with this - Apple has it and wants to remove it
<gregwhitworth> Rossen: do you want a resolution
<gregwhitworth> TabAtkins: The textarea one is simple enough to go into sizing 4
<gregwhitworth> TabAtkins: the iframe one can go in WICG
<gregwhitworth> Rossen: any objections to adding textareas to CSS Sizing L3
<gregwhitworth> fantasai: yes
<gregwhitworth> TabAtkins: I said 4
<gregwhitworth> Rossen: Ok, L4
<gregwhitworth> fantasai: ok - I'm ok with that
<gregwhitworth> Rossen: Changes to sizing L4
<fantasai> fantasai: we can add a note for L3
<gregwhitworth> Resolved: Add textarea sizing to Sizing L4
<fantasai> RESOLVED: Add textarea sizing to Sizing L4
<gregwhitworth> *discuss whether to do in WICG*
<gregwhitworth> TabAtkins to spin up a WICG regarding auto sizing of iframes
<tantek> I'm a bit surprised that we're not even putting into a WD something that's been shipping in iOS for 10 years
Member

css-meeting-bot commented Nov 6, 2017

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 full IRC log of that discussion <gregwhitworth> Topic: Auto resizing of iframes and textarea based on content size
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1771
<gregwhitworth> TabAtkins: there have been many requests for textarea and iframes resize on content
<gregwhitworth> TabAtkins: we talked it over and thought, yeah probably ok
<gregwhitworth> TabAtkins: we started experimenting with this
<gregwhitworth> TabAtkins: figure our some mechanism content based sizing for textarea and iframes
<gregwhitworth> TabAtkins: we learned some issues impl seamless with iframes due to COR leaking information
<gregwhitworth> TabAtkins: we suspect we'd walk up the frame tree until we hit a fixed size to resolve the mqs
<gregwhitworth> TabAtkins: Someone from Moz impl this
<gregwhitworth> dbaron: we got the spec to say that's how media queries work, but seamless was removed
<gregwhitworth> dbaron: we have code for it - but it's not necessarily something you can write up in a spec
<gregwhitworth> dbaron: you need to figure out how to spec it
<gregwhitworth> iank_: what type of interesting things
<gregwhitworth> dbaron: I'd need to look, like it tries to do layout
<fantasai> s/do layout/do layout, and then tries again/
<gregwhitworth> rossen: we used to have a technology that would allow you to do layout based on then content size and we killed it
<smfr> q+
<gregwhitworth> Rossen: performance becomes a concern for those
<tantek> The iframe use-case for me is known width (set by container), auto (preferably auto-expanding) height
<gregwhitworth> Rossen: when you consider extensions they try to size the box, and it's shrink to fit it becomes very bad for perf
<gregwhitworth> Rossen: Our experimentation for this suggests it was bad, but maybe you'll find something
<gregwhitworth> TabAtkins: they're both pretty separate features anyways
<Rossen> q?
<gregwhitworth> TabAtkins: are we ok experimenting in this space
<gregwhitworth> TabAtkins: the textarea would go into sizing 4
<gregwhitworth> smfr: we've had the auto sizing of the iframe even COR
<gregwhitworth> smfr: it makes your frame layout outside in rather than inside out
<gregwhitworth> smfr: we've had quite a few media query bugs
<gregwhitworth> smfr: we ran into media query cycles
<gregwhitworth> TabAtkins: that means that you weren't doing media queries the way we defined
<smfr> q-
<gregwhitworth> smfr: it does bring about nasty things in the code
<gregwhitworth> TabAtkins: how is this different from regular layout
<gregwhitworth> smfr: you can avoid laying out the iframe, if you have to you have to dirty the other nodes
<gregwhitworth> TabAtkins: ok, let's talk about this later
<gregwhitworth> dbaron: I think the media query problems you had were due to doing what authors weren't expecting
<gregwhitworth> TabAtkins: this would be opt in
<gregwhitworth> tantek: how do you trigger behavior in iOS
<gregwhitworth> smfr: you always get it
<gregwhitworth> smfr: users don't experience nested scrollers, we always wanted page scrolling to win so you don't get trapped
<gregwhitworth> tantek: width is expected and height is auto
<gregwhitworth> smfr: yes
<gregwhitworth> Rossen: ok, so - it seems that Google wants to experiment with this - Apple has it and wants to remove it
<gregwhitworth> Rossen: do you want a resolution
<gregwhitworth> TabAtkins: The textarea one is simple enough to go into sizing 4
<gregwhitworth> TabAtkins: the iframe one can go in WICG
<gregwhitworth> Rossen: any objections to adding textareas to CSS Sizing L3
<gregwhitworth> fantasai: yes
<gregwhitworth> TabAtkins: I said 4
<gregwhitworth> Rossen: Ok, L4
<gregwhitworth> fantasai: ok - I'm ok with that
<gregwhitworth> Rossen: Changes to sizing L4
<fantasai> fantasai: we can add a note for L3
<gregwhitworth> Resolved: Add textarea sizing to Sizing L4
<fantasai> RESOLVED: Add textarea sizing to Sizing L4
<gregwhitworth> *discuss whether to do in WICG*
<gregwhitworth> TabAtkins to spin up a WICG regarding auto sizing of iframes
<tantek> I'm a bit surprised that we're not even putting into a WD something that's been shipping in iOS for 10 years
@tantek

This comment has been minimized.

Show comment
Hide comment
@tantek

tantek Nov 7, 2017

Contributor

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.

Contributor

tantek commented Nov 7, 2017

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.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Nov 15, 2017

Contributor

@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.

Contributor

fantasai commented Nov 15, 2017

@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.

@Nadya678

This comment has been minimized.

Show comment
Hide comment
@Nadya678

Nadya678 Jan 7, 2018

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.

Nadya678 commented Jan 7, 2018

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.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Feb 6, 2018

Contributor

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

Contributor

fantasai commented Feb 6, 2018

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

@fantasai fantasai changed the title from [css-sizing] Auto-resize iframes and textarea based on content to [css-sizing] Auto-resize iframes based on content Feb 6, 2018

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Mar 4, 2018

Contributor

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

Contributor

fantasai commented Mar 4, 2018

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

@Malvoz

This comment has been minimized.

Show comment
Hide comment
@Malvoz

Malvoz Oct 16, 2018

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.

Malvoz commented Oct 16, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment