Re: Allow auto-resize on iframe

> On Feb 17, 2016, at 4:08 pm, Ojan Vafai <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