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
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC