A fluid-width srcset is generated when a height is passed about js-core HOT 13 CLOSED

After discussing it internally, we've decided that this logic should be revised to produce a fixed-size srcset when passed a height.

from js-core.

I had to do a double-take on this and I may need another look, but the documented/intended behaviour says that a DPR-based srcset is generated if:

• a width or
• both a h and ar are passed

This test:
https://github.com/imgix/imgix-core-js/blob/4caab96c42e2717942c4c8b6fdfe972994c8c9e8/test/test-buildSrcSet.js#L592

https://github.com/imgix/imgix-core-js/blob/4caab96c42e2717942c4c8b6fdfe972994c8c9e8/test/test-buildSrcSet.js#L598

demonstrates this behavior.

from js-core.

Yep @ericdeansanchez you're correct that this is "intended behaviour", but is it the right behaviour?

from js-core.

Yeah, I agree with that sentiment and I think this topic is really worth looking into.

I also think the specifics matter, ie. what portion of the above is right/wrong? As in, what is

client.buildSrcSet('/image.jpg', { h: 100 });

trying to express? Does it represent a valid or invalid operation?

I think the reasoning behind requiring ar and h is to preserve the dimensions/ratios. If not passed with ar, h is ignored when deciding whether to generate a DPR srcset...

Are you saying that there should be a way to specify a fixed-height without specifying an aspect ratio so that the result is a DPR-based srcset?

from js-core.

Yeah, I agree with that sentiment and I think this topic is really worth looking into.

Great!

I also think the specifics matter, ie. what portion of the above is right/wrong? As in, what is

client.buildSrcSet('/image.jpg', { h: 100 });

trying to express? Does it represent a valid or invalid operation?

This is a valid operation, just as much as client.buildSrcSet('/image.jpg', { w: 100 }); is a valid operation.

I think the reasoning behind requiring ar and h is to preserve the dimensions/ratios. If not passed with ar, h is ignored when deciding whether to generate a DPR srcset...

This is true, using ar sets the aspect ratio, and then specifying either w or h fixes the images dimensions according to that aspect ratio. You're totally right that h is ignored if ar is not set.

The issue

Let's not get distracted from the main issue here. If I pass just a h to buildSrcSet, the srcset that is generated changes its aspect ratio for every srcset generated.

e.g. the first srcset could be image.jpg?w=100&h=100 100w, and the second is image.jpg?w=116&h=100 116w. We can see the aspect ratio changes from 1:1 to 1.16:1 from the first to the second srcset. This can surely not be the intended effect of the operation. This is crystal clear when we compare it to the effect when generating a srcset without w or h set - the aspect ratio is the same between srcsets.

Are you saying that there should be a way to specify a fixed-height without specifying an aspect ratio so that the result is a DPR-based srcset?

Kind of. I'm not saying that we should create a new method to do this, I'm saying that buildSrcSet should behave in this way when just an h is passed.

from js-core.

Ah! Okay, cool now I get what you're saying. Let's sync up to make sure the behaviour here is both expected and correct. Also, thanks for this:

Let's not get distracted

I think there were a couple nuances here that I got confused/distracted by 😅

from js-core.

e.g. the first srcset could be image.jpg?w=100&h=100 100w, and the second is image.jpg?w=116&h=100 116w. We can see the aspect ratio changes from 1:1 to 1.16:1 from the first to the second srcset. This can surely not be the intended effect of the operation.

This is definitely bad behaviour. All entries in a srcset are supposed to be the same aspect and the same crop, just at different scales. They're not meant for art direction; that's what the picture element is for. Browsers aren't required to load the closest candidate from a srcset to the current conditions so site authors cannot rely on that assumption. For example, Chrome will keep an already-downloaded larger image and keep using it even if the viewport is resized to be smaller and a different candidate is closer.

from js-core.

"fixed-size srcset" doesn't sound like a srcset at all, or sounds like a single entry. Do you mean fixed aspect?

from js-core.

I see how that can be confusing. But yes, I mean it will generate a DPR srcset with pixel density descriptors rather than width descriptors.

from js-core.

I might be getting off topic now but it raised a concern when I thought about one of my current use cases, where I wouldn't want to suddenly find I'm getting a DPR srcset rather than a width descriptor one.

Would it support this use case:

Say I have an original high-resolution image, and I want a particular crop of this to be displayed full bleed. To define the crop I'd want to specify either aspect ratio or width and height, plus offset or gravity or however it's specified for Imgix; but I then want various scales of that crop to make it to the srcset. Does that make sense?

from js-core.

Yes I think it would still support it. In that case, you would want to use the aspect ratio parameter (ar) instead of defining a width and height. Let me know if I understand your use case correctly:

• Take this original image
• Crop it by a specific aspect ratio: ...?fit=crop&ar=3:2
• Give it an offset (or use focal points): ...?fit=crop&ar=3:2&fp-x=.06&fp-y=.75&fp-z=2&crop=focalpoint

To have that specific crop at various scales, we'd just have to provide these parameters to the buildSrcSet function:

const ix = new ImgixClient({
    domain: "ontologic.imgix.net",
    includeLibraryParam: false
});

const srcset = ix.buildSrcSet("nz1.jpg",
{
    fit:"crop",
    ar: "3:2",
    "fp-x": .06,
    "fp-y": .75,
    "fp-z": 2,
    crop: "focalpoint"
});

https://ontologic.imgix.net/nz1.jpg?fit=crop&ar=3%3A2&fp-x=0.06&fp-y=0.75&fp-z=2&crop=focalpoint&w=100 100w,
https://ontologic.imgix.net/nz1.jpg?fit=crop&ar=3%3A2&fp-x=0.06&fp-y=0.75&fp-z=2&crop=focalpoint&w=116 116w,
https://ontologic.imgix.net/nz1.jpg?fit=crop&ar=3%3A2&fp-x=0.06&fp-y=0.75&fp-z=2&crop=focalpoint&w=134 134w,
                                                 ...

The library also allows you to customize the widths if you don't want to use the default ones.

from js-core.

Yup, you understood my use case perfectly. So I guess as long as nobody's going to attempt the crop by using width/height, they're fine and won't suddenly find they have an unexpected DPR srcset.

from js-core.

🎉 This issue has been resolved in version 0.3.0-beta.1 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

from js-core.