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

Re: Allow auto-resize on iframe

From: Ojan Vafai <ojan@chromium.org>
Date: Thu, 18 Feb 2016 00:18:26 +0000
Message-ID: <CANMdWTsHgN0QRLNj+wo+iSs6geSrjJ4N9cXt3dDzJzw1DV4Ceg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Craig Francis <craig.francis@gmail.com>
Cc: 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

To be clear, I haven't run this by other folks who work on Chrome, so I'm
not making a definitive, formal "we won't implement this" statement here.
But, I strongly suspect other Chrome rendering folks would agree with me

> 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. :)
>> Assuming no, what spec does this go in?  Sizing?
>> ~TJ
Received on Thursday, 18 February 2016 00:19:09 UTC

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