- From: Ojan Vafai <ojan@chromium.org>
- Date: Fri, 19 Feb 2016 05:01:03 +0000
- 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>
- Message-ID: <CANMdWTtXx4bgLPNb4M8uJ-RDR0itm26fmgeaozvuJE-_H=t6DQ@mail.gmail.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