Re: Allow auto-resize on iframe

Sorry, Ojan, I completely disagree.

Your ResizeObserver solution may fix your immediate rendering loop problems in Chrome, but the end user will still see a rendering loop, as the iframe will still jump between two or more sizes (but now there is a few ms gap between them).

This is why I think a single pass is all that's needed.

If an auto-resizing iframe trips some weird conflicting media query (hopefully quite rare), then don't resize a second time, and let there be scroll bars.

This is be a much better experience for end users, who can now at least use the website.

Having said that, I'm really glad to see this is a Chrome specific issue, as Webkit already has a full solution (aka frame flattening), and Robert has confirmed that they have already done the work in Gecko a few years ago:

https://lists.w3.org/Archives/Public/www-style/2016Feb/0067.html <https://lists.w3.org/Archives/Public/www-style/2016Feb/0067.html>

I'll see if I can get in contact with the MS Edge team (or does anyone know who best to contact about this?).

Craig




> On 23 Feb 2016, at 00:22, Ojan Vafai <ojan@chromium.org> wrote:
> 
> To be clear, I think this use-case is extremely valuable. But I don't think we should add declarative features for every feature that requires a bit of script. That said it is far too hard to implement this behavior today. Before I worked on browsers, I built web sites and had to build exactly this code. It was really painful. 
> 
> It might make sense to add a declarative feature here eventually, but we should start with the imperative primitives and see how authors do with it. The advantage of providing lower-level APIs like this is that we enable a broad swath of new capabilities with one API. That way we get the most bandwidth out of browser implementers' limited bandwidth to add new features. Working on features like this means there's some other API we can't spend our time on implementing.
> 
> If we build ResizeObserver and find that in fact authors are doing this pattern all over the place on the web, then we can bake it into the platform at that time.
> 
> The code involved once we have ResizeObservers is not painful. It's something most web authors could copy off of StackOverflow. Off the top of my head, I think you'd write something roughly like this.
> 
> // Inside the iframe.
> var resizeObserver = new ResizeObserver(function(entries) {
>   var lastEntry = entries.pop();
>   window.frameElement.style.width = lastEntry.width;
>   window.frameElement.style.height = lastEntry.height;
> })
> resizeObserver.observer(document.documentElement);
> 
> One issue here is that it will only work for same-origin frames. I think we could provide an API where a page can opt it's cross-origin frames into being able to set their width/height, which also has many use cases outside of this specific one.
> 
> On Mon, Feb 22, 2016 at 3:56 AM Craig Francis <craig.francis@gmail.com <mailto:craig.francis@gmail.com>> wrote:
> On 22 Feb 2016, at 09:06, Xidorn Quan <quanxunzhen@gmail.com <mailto:quanxunzhen@gmail.com>> wrote:
> >
> > On Mon, Feb 22, 2016 at 4:35 PM, Lea Verou <lea@verou.me <mailto:lea@verou.me>> wrote:
> >> Regarding the security issues, CORS could be one solution, but not a great
> >> one as few websites enable it. What about not being able to read the
> >> computed height if the iframe is cross-origin? Similarly to how one can't
> >> read the computed style applied with :visited.
> >
> > Impossible. It is too many ways to know the height of an element,
> > given it affects layout. Applying restriction to ":visited" is
> > possible because we restrict that only "color" is applied for
> > ":visited", nothing else. And even for this very simple case (only
> > paint is affected), large complexity has been added, at least in
> > Gecko.
> 
> 
> 
> I believe the current proposal is to use a new header (even if temporary):
> 
>     Expose-Height-Cross-Origin: 1;
> 
> The discussion is at:
> 
> https://github.com/whatwg/html/issues/555#issuecomment-177797476 <https://github.com/whatwg/html/issues/555#issuecomment-177797476>
> 
> And thanks Lea, I realise I was going off on a bit of a tangent there :-)
> 
> Craig