Re: Allow auto-resize on iframe

On 18 Feb 2016, at 04:25, Simon Fraser <smfr@me.com> wrote:

> I disagree that it’s hard; WebKit has this code for iOS, and already expands almost all iframes to the size of the content. We call it “frame flattening”.



Thanks Simon, I'm really impressed that Safari has this feature already.

To be honest, as a website developer, I'd be happy with an even simpler implementation though (ref Chrome).

As far as I'm aware, iframes only need to scale in height, and media queries typically target the width.

So for most web pages, I think you could just set and lock the height after the first rendering pass (this will need to be re-done when the content changes though).

After that, continue to treat the iframe as we do today... so after this first pass, if the content no longer fits, then sod it, let a scroll bar appear. I think this will still keep most developers happy.

And I'm sure website developers will be able to work out what is causing the scroll bars to still appear. But maybe the browsers could help add a note in the Developer Tools, maybe in the Element > Styles panel, just to say what the height was set to (aka getComputedStyle)... something like:

> iframe {
>  height: max-content; // 307px
> }


Craig






> On 18 Feb 2016, at 04:25, Simon Fraser <smfr@me.com> wrote:
> 
>> On Feb 17, 2016, at 4:08 pm, Ojan Vafai <ojan@chromium.org <mailto:ojan@chromium.org>> wrote:
>> 
>> On Wed, Feb 17, 2016 at 2:28 PM Tab Atkins Jr. <jackalmage@gmail.com <mailto:jackalmage@gmail.com>> wrote:
>> On Tue, Jan 26, 2016 at 11:23 AM, Tab Atkins Jr. <jackalmage@gmail.com <mailto:jackalmage@gmail.com>> wrote:
>> > * Define "height: max-content" to mean content-size for <iframe>s.
>> > This is a new value that shouldn't have any web-compat burden.
>> [snip]
>> > And agree with zcorpan that cross-origin <iframe>s would need to opt
>> > in somehow (maybe CORS is enough?) in order to get this behavior.
>> 
>> So it seems like the WG generally agrees that "height: max-content" on
>> <iframe> should enable this behavior for same-origin iframes.  And per
>> roc's suggestion, such an iframe would use the outer frame's height
>> when evaluating MQs.
>> 
>> Anyone object to this?
>> 
>> I think it's a useful feature, but I also suspect that Chrome won't implement it because it introduces the same complexity that seamless did on the rendering code, which is to say that the layout of the iframe in the outer page is tied to the layout of the iframe contents, which is not a thing that's possible today. The marginal benefit to web authors didn't justify the added complexity to us.
> 
> I disagree that it’s hard; WebKit has this code for iOS, and already expands almost all iframes to the size of the content. We call it “frame flattening”. I don’t recall when Blink forked, but it’s possible this code was in WebKit at the fork point.
> 
> However, it is the cause of a number of ugly crashes and performance issues, since layout inside a frame can trigger layout of ancestor frames. We’ve talked about making the inner frame layouts asynchronous (so you might see a flash of wrongly-sized iframe) to ameliorate some of the problems.
> 
> Simon
>