Re: Allow auto-resize on iframe

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


>
> Assuming no, what spec does this go in?  Sizing?
>
> ~TJ
>
>

Received on Thursday, 18 February 2016 00:08:57 UTC