W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: Allow auto-resize on iframe

From: Ojan Vafai <ojan@chromium.org>
Date: Fri, 19 Feb 2016 05:01:03 +0000
Message-ID: <CANMdWTtXx4bgLPNb4M8uJ-RDR0itm26fmgeaozvuJE-_H=t6DQ@mail.gmail.com>
To: Simon Fraser <smfr@me.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Craig Francis <craig.francis@gmail.com>, www-style list <www-style@w3.org>, Aleks Totic <atotic@google.com>, Elliott Sprehn <esprehn@google.com>, Ian Kilpatrick <ikilpatrick@google.com>
On Wed, Feb 17, 2016 at 8:25 PM Simon Fraser <smfr@me.com> wrote:

> 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>
> wrote:
>
>> On Tue, Jan 26, 2016 at 11:23 AM, Tab Atkins Jr. <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.
>

Yup. We did have this code 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.
>

Heh, these are exactly the problems I had in mind that were hard (relative
to the value of the feature that is). :) I don't think they're
insurmountable, but I'd rather we not add the complexity of doing this
synchronously to the platform.


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

If we do add ResizeObserver and it's ~5 lines of code to make this work,
I'd be fine asking authors to do that. I'd also be fine with defining the
max-content thing to work at ResizeObserver timing and implementing that.
That actually avoids users seeing wrongly-sized iframes (because layout
loops) *and* avoids the crash issues, but it means that offsetHeight on the
iframe will sometimes give you a stale result.


> Simon
>
>
Received on Friday, 19 February 2016 05:01:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC