Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What should viewport relative images do between viewport resize and image loading? #246

Open
yoavweiss opened this issue Sep 30, 2014 · 7 comments

Comments

@yoavweiss
Copy link
Member

I'm working on fixing a Blink bug @zcorpan filed, where the DPR of the loaded resource is applied before the resource has actually loaded, causing the previously loaded resource to change dimensions when resizing the viewport, before the new resource was loaded.

I wonder what that behavior should be though.

OTOH, you could claim that the previous resource should not be stretched beyond its "natural" width, otherwise quality may suffer.
On the other, you could claim that having image dimension change when the resource is finally loaded (and having a smaller image than anticipated before that) can result in broken layout during these periods.

I tend to think that the latter is the better option. Anyone has an opinion on the matter? Should we codify that in the spec?

@yoavweiss
Copy link
Member Author

OTOH, if the viewport resize goes beyond <source> boundaries, we could argue that it'd be better to keep the previous image at its "natural" width and not more than that. (or some other behavior altogether).

@eeeps
Copy link

eeeps commented Oct 1, 2014

Gut, ill-considered, reaction:

  • When switching from one srcset resource to another, continue to display the old resource at the new intrinsic dimensions while we wait for the new resource to load. Worst case: it gets a little fuzzy in the interim. Alternative worst case: the image’s size suddenly jumps, unprompted, long after we’re done resizing the window.
  • When a source media turns false, stop displaying the old resource immediately. There’s no good guess here about what to do in the interim, as we don’t know anything about the new, art-directed resource or how it’s supposed to slot into the layout.

@zcorpan
Copy link

zcorpan commented Oct 1, 2014

Not showing anything seems like a bad user experience.

If it's shown and doesn't break the layout, there's no problem. If it breaks the layout, the author can set the right size in CSS and use object-fit to preserve aspect ratio. We might also add width/height information for source at some point also, removing the need to use CSS.

@zcorpan
Copy link

zcorpan commented Jan 20, 2015

When images have different aspect ratio, both alternatives have potential to break the layout:

A http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3375
vs
B http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3376

I think showing the old image at the old dimensions is less disruptive.

If the author has set the height of the image, we get no change in behavior for A while B stretches (and doesn't break the layout):

B http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3377

Possibly an ideal would be to wait with switching the layout until all the new images have loaded. However, that could take a long time. It doesn't seem like something we should do by default, but maybe something that we should provide hooks for so that authors can implement that behavior without having to avoid using srcset/picture. (For instance, a cancelable event when switching an image allows the author to abort/delay switching the image until all images have loaded, plus a method to rerun the "environment changed" algorithm to apply the change, and a property indicating whether the wanted candidate is still loading.)

The spec currently requires A. It is worse for DPR, but better for art direction. Differentiating the two in behavior seems like it would be a source of bugs and confusion. I think it is better to keep A as the default behavior and let authors override it with CSS.

@tabatkins
Copy link

You shouldn't be changing the aspect ratio with a srcset attribute; it violates the assumption that the sources are all the same image, just at different resolution. Thus, for any decision we make regarding aspect ratios, we can ignore its effect on DPR-based switching, as it'll only have an effect when people are misusing the feature in ways that are broken on their face.

Thus, if A is better for art-direction, let's go with it. (I can't tell, because both of your examples do their thing far too fast for me to see any effect at all.)

@zcorpan
Copy link

zcorpan commented Jan 20, 2015

Right but it can still change in size because of sizes.

<img srcset="foo 200w, bar 400w, baz 800w" sizes="(min-width: 500px) 50vw, 100vw">

When you cross the breakpoint, and need a bigger image, what do you do while it is downloading? Keep the old size? Continue to normalize the density with the new sizes? Or the old sizes?

In my examples you can increase the timeout from 1000ms to 2000ms or whatever. It's intended to simulate slow network so that loading the image takes a while.

@zcorpan
Copy link

zcorpan commented Jan 20, 2015

(Actually the example in the chrome bug is simpler than that: <img sizes="100vw" srcset="foo 800w, bar 1600w">)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants