Re: Allow auto-resize on iframe

Hi TJ,

I agree that ResizeObserver (which still requires developers to implement with JavaScript) will avoid a situation where the resizing does not crash the browser.

But the browser can create a much better fix for everyone with CSS, even if it only did a single attempt at setting the height before falling back to scroll bars (i.e. when it notices a loop).

I certainly appreciate that you are trying to trying to be good stewards, and not make the web more complicated than it is... but iframe auto-reising is something that developers have been requesting for over 2 decades, it has many use cases, and it sounds like Safari and Firefox are able to implement it already (where they have a much better solution than the simple single-pass approach, which would still be good enough).

---

As to why I think the usefulness of ResizeObserver has few use cases, well if the browser could address the main problem of the iframe auto-resizing with height: max-content; then I can't really see myself ever needing/using ResizeObserver.

The remaining 3 examples mentioned on the "explainer" document:

https://github.com/WICG/ResizeObserver/blob/master/explainer.md <https://github.com/WICG/ResizeObserver/blob/master/explainer.md>

They can already be done with existing JavaScript events (e.g. window resize) and CSS... yes ResizeObserver will tidy up some of the edge cases, and make the coding a little bit easier, but ultimately it's a nice to have (whereas iframes today are broken, so many developers just don't use them - instead allowing third parties to run JavaScript on the page to add content, e.g. Disqus).

As to the implementation delay for ResizeObserver... I was more referring to the fact it will take a while to be implemented, and once available, there is pretty much no reason for every website developer to change their existing hacky solution for a different hacky solution.

Ideally we would have a solution that addresses the iframe height problem (one we know exists), and that really does include cross origin content, and height changes due to page navigation (assuming the ResizeObserver works within the iframe document, as per Ojan's example).

Craig





> On 23 Feb 2016, at 23:08, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Tue, Feb 23, 2016 at 1:37 AM, Craig Francis <craig.francis@gmail.com> wrote:
>> 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).
> 
> Yeah, this ends up being similar to :hover loops, which cycle at a
> speed the user can actually see.  Moving the loop into internal logic
> means we actually need to address it; we can no longer say "don't do
> that" if it hard-locks an algorithm.
> 
> On Tue, Feb 23, 2016 at 1:37 AM, Craig Francis <craig.francis@gmail.com> wrote:
>> 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?).
> 
> The distinction is very porous and wishy-washy. Good as a general
> principle, but don't worry about trying to guide behavior from it.
> 
>> 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:
> 
> This are specific reasons for this that don't apply to the scenario
> we're talking about.
> 
>> So I think ResizeObserver is going in the wrong direction. It might be
>> useful in some rare cases, but not so much here.
> 
> How is it not useful here?  What "rare cases" are you imagining it
> being limited ot?
> 
>> 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.
> 
> All approaches are bad, for various reasons.  Note, tho, that this is
> *not* trying to "fix everything", in fact it's doing the exact
> opposite - it's trying to identify the *one* piece of missing
> functionality (easy notification of when an element changes size) and
> providing just that, relying on JS's status as a general-purpose
> language to hook it up to any specific use-cases.  We've been trying
> to use this strategy for new features in the web platform for a few
> years now, and it's starting to pay off.
> 
> 
> On Tue, Feb 23, 2016 at 1:45 AM, Lea Verou <lea@verou.me> wrote:
>>> On 23Feb, 2016, at 04:37, Craig Francis <craig.francis@gmail.com> wrote:
>>> 
>>> Just to add to this (again, going a bit off topic, please feel free to ignore)....
>>> 
>>> [snip]
>>> 
>>> 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.
> 
> "It will take a long time to be implemented" is a common but invalid
> reason to support a *different* unimplemented solution.
> height:max-content wouldn't happen any *faster* - the hard part is the
> plumbing inside the browser, which would be identical for either case.
> 
> Or worse - if you do require sync resize, the code is more complex
> than allowing a frame of delay.  But this isn't important for the 90%
> use-case, which is just using sandboxed iframes as a safe way to host
> untrusted content - at worst, async resize will give a frame of
> flicker during the initial layout.
> 
> So if the implementation delay is sufficient to make you think you
> wouldn't use ResizeObserver, then it's sufficient to make you think
> you wouldn't use height:max-content either.  In either case you'll
> have to wait for implementations, and deploy a polyfill for legacy
> browsers.  And that's assuming that the two of them would have
> perfectly equivalent timelines.
> 
>> Again, completely agreed with Craig. I’m not quite sure how this convoluted ResizeObserver solution is better than what we currently have, given that it's also same origin (or did I misunderstand?).
> 
> It's better than the code you have to write *today* to get the same
> effect.  Do you honestly think those five lines are "convoluted"?
> They seem ridiculously straightforward and simple to me, roughly the
> easiest it can possibly be made in script - watch the internal <html>
> for resizes, then resize the outer <iframe> element based on that.
> 
>> Good thinking re:general APIs first and shortcuts later, but there *is* such a thing as too much generalization. Let's not turn the Web platform into Java, please.
> 
> I don't understand what you mean by this.  The EWP manifesto is not
> about turning anything into Java.  The browser standard library is
> very big, and really weird and inconsistent.  We need to be better
> shepherds of expanding it, and one way to do that is to first always
> expand at the "new capability" level, which means in JS, because
> that's low-impact.  Afterwards, when we see usage and patterns, we can
> backfill declarative solutions based on the new capability.  Doing it
> the other way around has a really mixed track record.
> 
>> Also not sure what is meant by `// inside the frame` in the code sample. Is this code supposed to be called from inside the iframe? In that case, it doesn't solve the overwhelming majority of use cases for this, where the parent wants to resize the iframe and the iframe has no idea.
> 
> That was for simplicity; if you're starting from outside the iframe
> the code is just a teensy bit more complex to set up in reverse.  I
> recommend actually sitting down and understanding what the example is
> doing; it's relatively simple, and doing so would have answered these
> questions for you already.
> 
> ~TJ