ix_picture_tag provides wrong ouput of v3 about imgix-rails HOT 1 CLOSED

Hi @Jimmy89, thanks for the ticket.

After looking through the information you provided, I'm pleased (or displeased, from a certain perspective) to inform you that what you're seeing is the intended behavior of this library as of version 3.0. The output you included from our example page is out of date, it seems--that's on me. There was a bit of confusion surrounding the recent 3.0 release and apparently the examples were yet another thing I let slip through the cracks. I'll prioritize fixing those very soon.

In order to explain what's going on here, I'm going to take a step back and look at how the srcset and sizes attributes work, and how this meshes with the goals of this library. If you already know and understand this stuff feel free to skip over the next paragraph, but I'm going to put it in anyway for the sake of any less-experienced developers that may stumble across this ticket in the future.

When using <picture> and <source> to display responsive images, the browser decides which <source> element to use based on its media query, then selects which image URL to fetch from the <source> element's srcset list based on that <source> element's sizes attribute (which can be an absolute pixel value, or a relative value). While we'd love to be able to examine things as the browser does and provide a single perfect imgix URL for the given circumstances, unfortunately for us the information available at the time imgix-rail is doing its thing is tragically incomplete. So what we can do instead is provide a robust set URLs in the srcset list (by varying the rendered width via the w parameter) that the browser can choose a near-perfect image to display no matter what its selection mechanism settles on as its ideal width, height, and pixel density.

While I agree that on their face, the robust srcset lists we're providing may seem absurdly long, we feel quite strongly that this is the correct approach. As stated above, a robust srcset list allows your users' browsers to select the best possible image to fill any sized container at any screen resolution. Our default algorithm ensures that no matter the circumstances, the browser will always be able to choose an image that is within 8% of its rendered dimensions, which guarantees high visual fidelity for your end users and cuts down on wasted bandwidth. It may seem excessivley long, but the robust srcset can pay huge dividends for your users.

The cost of this robust srcset, on the other hand, is next to zero:

• It costs you nothing to generate: just call the helper function
• The additional HTML bytes shipped to your users are largely negligible compared to the bytes you save by ensuring they download a properly-sized image
• We've seen no negative performance implications for browsers parsing large srcset attributes

Are there things we can do to improve this code? Certainly. We could do a better job of examining the sizes value provided for each <source> element, and if we determine that the value provided represents an absolute pixel dimension (as your last breakpoint does) we could provide a more focused srcset that lists specific image dimensions at 2x, 3x, etc instead of our standard width array. We fully intend to improve this algorithm further over time, but this specific behavior isn't on the roadmap at the moment. If you or any of our community members following along would like to tackle this sooner, though, PRs are always welcome!

If you find yourself unconvinced, though, you can still pass your own widths list as an option when you call the ix_picture_tag helper to override the automatically-generated srcset list. However, in typing up this response I noticed a bug in that code (the widths argument doesn't seem to be passed through)--look for version 3.0.1 to come out shortly to address this.

Since there's no fix to be made here directly, I'm going to close this ticket, but I'm happy to continue discussing if you have further questions or concerns.

from imgix-rails.