Re: Allow auto-resize on iframe

On Thu, Feb 18, 2016 at 11:32 PM Tab Atkins Jr. <>

> On Thu, Feb 18, 2016 at 9:01 PM, Ojan Vafai <> wrote:
> > 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.
> I'm fine with speccing that.  A layout being observably stale is a new
> thing for CSS, but it's fairly minor.

Unless there is an implementer that really wants to implement modified
seamless or something here, my preference would be that we get serious
about specing/implementing ResizeObserver and then see if there's still
developer demand for more once that's shipped. We can always add something
declarative at that point. There is *huge* developer demand for
ResizeObserver (or something like it) regardless of what we do here for
other use cases.

> What are your thoughts on the MQ stuff?

Having MQ behavior change based off height:max-content seems a bit too
magic to me (not that you were suggesting that). If we want to change MQs
then we should bring back a modified, async version of seamless IMO. I
don't think we should do that.

Our answer to potential infinite loops here can just be "don't do that."
This doesn't strike me as substantially different than an infinite loop in
JS. We could spec a max number of loops through layout as we're considering
doing for ResizeObserver to avoid infinite loops (or just hang the page if
we don't add such a thing). Both seem fine to me.


Received on Friday, 19 February 2016 23:22:14 UTC