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

Re: Allow auto-resize on iframe

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 17 Feb 2016 16:15:15 -0800
Message-ID: <CAAWBYDD7LzMR5fAvkCCkTjH+HnhoRLv+oOsT07KkorvugofEVg@mail.gmail.com>
To: Ojan Vafai <ojan@chromium.org>
Cc: 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 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.
> That said, it's definitely too hard to do this yourself as a web author and
> we should absolutely fix that. In a future world in which we have
> ResizeObservers, it's a few lines of JS to get the equivalent of this as
> long as you're OK with it being slightly async (i.e. querying offsetHeight
> on the iframe will be stale until a frame is pumped). It's the slightly
> async-ness that makes it not incur the implementation complexity.
> This is similar in spirit to Element Queries. Implementing them with full
> fidelity synchronous layout behavior adds considerable complexity to the web
> platform and thus imposes a cost on content that doesn't use Element
> queries. Implementing them on top of ResizeObservers adds close to 0
> complexity to the platform, so the cost is eaten only by content that uses
> it.
> https://github.com/atotic/ResizeObserver/blob/master/explainer.md
> Not sure if that counts as objecting. :)

"We won't implement this" is the most basic form of objection possible.

Received on Thursday, 18 February 2016 00:16:10 UTC

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