W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: Allow auto-resize on iframe

From: Ojan Vafai <ojan@chromium.org>
Date: Tue, 23 Feb 2016 00:22:27 +0000
Message-ID: <CANMdWTsREqk2bfvJxLHGpfN9vH4FqzFZZzp8ipkwoMrFRdzK7A@mail.gmail.com>
To: Craig Francis <craig.francis@gmail.com>, Xidorn Quan <quanxunzhen@gmail.com>
Cc: Lea Verou <lea@verou.me>, Simon Fraser <smfr@me.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>, Aleks Totic <atotic@google.com>, Elliott Sprehn <esprehn@google.com>, Ian Kilpatrick <ikilpatrick@google.com>
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>
wrote:

> On 22 Feb 2016, at 09:06, Xidorn Quan <quanxunzhen@gmail.com> wrote:
> >
> > On Mon, Feb 22, 2016 at 4:35 PM, Lea Verou <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
>
> And thanks Lea, I realise I was going off on a bit of a tangent there :-)
>
> Craig
>
Received on Tuesday, 23 February 2016 00:23:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC