Re: Allow auto-resize on iframe

Just to add to this (again, going a bit off topic, please feel free to ignore)....



I don't care about your distinction between imperative and declarative, my view has always been that CSS focuses on styles and layout, and JavaScript focuses on the behaviour (anyone on the www-style mailing list like the confirm/deny this?).

I also believe the current recommendation is for JavaScript to simply add/remove classes on elements, rather than setting styles directly... as Paul Irish recently pointed out:

https://twitter.com/paul_irish/status/564443848613847040 <https://twitter.com/paul_irish/status/564443848613847040>

----

So I think ResizeObserver is going in the wrong direction. It might be useful in some rare cases, but not so much here.

My main concern is your comment "we enable a broad swath of new capabilities with one API".

I've heard this argument too many times before, rather than coming up with a nice and simple solution to a problem, there seems to be this desire to come up with a solution that fixes *everything*, but that solution often becomes too complicated to use, or simply never gets built.

And yes, I admit, I am a bit grumpy about this. A similar thing happened to my proposal to create a simple replacement for PDF's by wrapping HTML into a ZIP file (and applying a very strong sandbox), which was basically ignored by DigiPub-IG because "ePub and PWP can do all this, and so much more" (which was really missing the point):

https://github.com/craigfrancis/wdoc/ <https://github.com/craigfrancis/wdoc/>

----

In summary, I believe we already have too many JavaScript "solutions" trying to fix things missing from CSS (says he having recently set the height of the main page content because a sidebar had to be positioned absolutely - yes, I hated myself for doing it, no, I still can't use flexbox yet).

And I personally don't see myself using ResizeObserver, as it will take a very long time for it to be implemented, and I can't see how it will make any improvements over my current JavaScript "solution", which at least supports legacy browsers.

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