- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 17 Feb 2016 16:15:15 -0800
- To: Ojan Vafai <ojan@chromium.org>
- Cc: Craig Francis <craig.francis@gmail.com>, 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 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. :) "We won't implement this" is the most basic form of objection possible. ~TJ
Received on Thursday, 18 February 2016 00:16:10 UTC