Re: Allow auto-resize on iframe

I just want to clarify a couple things:
1. In the code snippet I showed, the user would not see flicker given the
way ResizeObserver is specced to loop. A solution where the user saw
flicker would be unacceptable IMO.
2. WebKit has frame-flattening, but it's not exposed in a way that web
authors have meaningful control over.

On Tue, Feb 23, 2016 at 3:08 PM 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
>