On Thu, Feb 18, 2016 at 11:32 PM Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Thu, Feb 18, 2016 at 9:01 PM, Ojan Vafai <ojan@chromium.org> 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. ~TJ >
Received on Friday, 19 February 2016 23:22:14 UTC