Re: [OT] Allow auto-resize on iframe

On 18 Feb 2016, at 00:08, Ojan Vafai <ojan@chromium.org> wrote:

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




What follows is fairly off topic and is not helpful to this discussion.

It is more of a rant, and I should add that I'm not in a good mood (for other reasons).

So I would suggest that you stop reading now, and instead have a look at my second email, which tries to discuss this properly.




--------------------------------------------------

Any website developer who has added a iframe to their website will know about the problem of setting the iframes size (typically just the height).

You NEVER want to crop the content, so browsers end up using ugly/broken scroll bars to alleviate that problem.

This situation is confirmed by the hard work that the Safari developers did to implement “frame flattening”, because iframes with scrollbars are nasty (thank you Simon btw).

For the website developers (who cannot rely on users being on iOS), they now need to know about the content the iframe will contain.

Ahead of time, you can only guess the content MIGHT be something like 307px high... so the only alternative is to use some VERY buggy JavaScript to do the calculations, and manually change the height as needed.

And trust me, the JavaScript for this is VERY buggy.

I've had to work around this problem many times, and I'm certainly not the only one... ANYONE who has worked with iframes will have worked arround this problem, and NONE of them have any good solutions (I've wasted many hours, over many times, looking for a good solution).

This is a MASSIVE problem and it hasn't been addressed since it started rearing it's ugly head in 1997 (when Internet Explorer introduced iframes).

Many developers were complaining, as they JUST wanted the iframe to have an auto-height.

Shortly afterwards, the browser developers suggested "we can introduce [seamless], that will fix your problems, and so much more!".

The general reaction from developers was more along the lines of "Whatever, as long as the height is correct, we don't really care about the rest of its features".

This discussion was happening around 2000, one bug report in particular being raised in 2001:

https://bugzilla.mozilla.org/show_bug.cgi?id=80713 <https://bugzilla.mozilla.org/show_bug.cgi?id=80713>

Since then, many developers have continued to work around this problem, where browser developers kept saying that [seamless] was coming... one day.

But that day never came, and as of January 2016, seamless finally (and fortunately) died.

And it needed to die, it was far to complicated, and only 1 part of it addressed the problems that developers were experiencing... I've yet to find a situation where anyone has really needed the parent document styles to apply to the iframes content.

----

So now this discussion is looking at this new ResizeObserver, which still requires JavaScript... and I must confess, I'm REALLY not impressed.

I have this feeling it's yet another complicated solution that means EVERYONE needs to wait another 15 years while no browsers implement it, for it to also be killed off.

----

And by "wait", what I mean is continue to implement even more work arounds.

For example, iframes provide a fantastic way to add content from third party websites, and keeping it isolated (really good for security, something I think Mike West might have something to say about).

Unfortunately we cant use iframes, because their content often changes, and will therefore not fit within the fixed size of the iframe.

And because most developers can't be bothered to implement custom postMessage() code (as this NEEDS to work cross domain), nor can they get this JavaScript to fire every time the content changes (even if waiting for an image of unknown size to load), they instead ditch the idea of a nice and safe iframe, and just use a <script> tag on the parent page, which typically uses document.write().

And we all know how messed up websites are when they copy/paste <script> tags, from 30+ different untrusted/unreliable content providers.

These <script> tags then allow the 3rd party sites FULL access to the page, to do whatever they like (hopefully they will just add their widget in the defined space, but they can now also do so much more).

Oh, and these <script> tags, they are rarely (aka never) async... so they cause the page to block rendering, which is a very common problem (imagine what happens when a school or company decides to blackhole the DNS for twitter.com).

On the other hand, if the widgets could use iframes (e.g. think of a Twitter timeline), then Twitter would not be making any decisions on where the widget appears, it won't be able to edit the content of the parent page, it would't be able to block rendering (if the iframe does not load, oh well, you now have a small white space on the page)... and they cannot steal cookies (as so few websites mark them as httpOnly), or log the key presses when someone goes to login, or change the login form's action to a different server (because I can guarantee the website hasn't implemented a CSP header which limits `form-action`).

----

So no, I REALLY dislike this comment about a "marginal benefit to web authors didn't justify the added complexity to us".

It is a MASSIVE benefit to web authors, and if you were to actually implement it in your browser ONCE, then EVERYONE will benefit from it.

And I'm not saying it has to be a perfect implementation either, as you will see in my second email.

But if every browser but Chrome implements this, I'd still be very happy, and I'd probably still rip out my JavaScript and replace it with:

iframe {
    height: 100000px;
    height: max-content;
}

And just let my websites look really bad on Chrome... because at least that works, it would look ugly in Chrome, but it works.

--------------------------------------------------

Ok, I feel a bit better... now back to the discussion.

Craig


























> On 18 Feb 2016, at 00:08, Ojan Vafai <ojan@chromium.org> wrote:
> 
> 
> 
> On Wed, Feb 17, 2016 at 2:28 PM Tab Atkins Jr. <jackalmage@gmail.com <mailto:jackalmage@gmail.com>> wrote:
> On Tue, Jan 26, 2016 at 11:23 AM, Tab Atkins Jr. <jackalmage@gmail.com <mailto: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 <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
>