Re: Allow auto-resize on iframe

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

Received on Tuesday, 23 February 2016 23:08:54 UTC