-
Notifications
You must be signed in to change notification settings - Fork 35
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
Comments
OTOH, if the viewport resize goes beyond |
Gut, ill-considered, reaction:
|
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 |
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 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. |
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.) |
Right but it can still change in size because of
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 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. |
(Actually the example in the chrome bug is simpler than that: |
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?
The text was updated successfully, but these errors were encountered: