Re: Allow auto-resize on iframe

On 24 Feb 2016, at 01:10, Ojan Vafai <ojan@chromium.org> wrote:

> 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.




Hi Ojan,

May I ask why you think ResizeObserver won't show a flicker?

Going with your *same-origin* example, we start with the iframe loading (DOMContentLoaded), where it goes to the parent document to set its iframe height:

 var iframe = parent.document.getElementById('iframe');
 if (iframe) {
   iframe.style.height = height + 'px';
 }

So exactly what web developers do at the moment... but it then goes on to register ResizeObserver for it's own content:

 var resizeObserver = new ResizeObserver(function(entries) {
   var lastEntry = entries.pop();
   iframe.style.height = lastEntry.height + 'px';
 });
 resizeObserver.observer(document.documentElement);

This will be called when the current document changes it's content / size (this solution ignores navigation to a different page, e.g. form post).

Now, let say the document is resized... maybe an image took a while to be loaded (and didn't have its width/height set), the css didn't load before DOM Ready, some JavaScript changed the content, etc.

The ResizeObserver will trigger, and update the height of the iframe.

BUT... as with the examples mentioned, there is a CSS media query based on the height of the canvas.

So the media query causes something on the page to be hidden, the ResizeObserver triggers again, which updates the iframe height, the media query no longer applies, and that element is shown again, the ResizeObserver triggers again, etc, etc.

Ultimately ResizeObserver does not address this problem at all... from a web developers point of view, it is pretty much the same as:

 window.addEventListener('resize', function() {
   iframe.style.height = height + 'px';
 });

Craig





> On 24 Feb 2016, at 01:10, Ojan Vafai <ojan@chromium.org> wrote:
> 
> 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 <mailto:jackalmage@gmail.com>> wrote:
> On Tue, Feb 23, 2016 at 1:37 AM, Craig Francis <craig.francis@gmail.com <mailto: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 <mailto: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 <mailto:lea@verou.me>> wrote:
> >> On 23Feb, 2016, at 04:37, Craig Francis <craig.francis@gmail.com <mailto: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