Re: Why doesn't the srcset attribute use actual image width?

What you've described is pretty much how responsive images already work.

The srcset attribute presents the different sizes of the same image, and
the browser may pick whichever it wants.

However, image start downloading before CSS has applied (except when using
loading=lazy), so the browser needs some way to figure out the CSS width of
the image in advance. This is what the sizes attribute does. See
https://jakearchibald.com/2015/anatomy-of-responsive-images/ for more
details.

Now the browser has the size of various versions of the image, and the CSS
size of the <img>, it picks the best item in the srcset based on pixel
density, size, connection speed, etc etc.


On Sun, 22 Dec 2019, 20:58 Leonid Jakobson, <leonid.jakobson@gmail.com>
wrote:

> The `srcset` attribute allowed for great strides in web accessibility and
> efficiency. However, its potential seems to not be properly utilized with
> its current
> implementation.
>
> Currently, the `srcset` spec, along with its `sizes` neighbor, forces the
> user agent to utilize screen size to pick the optimal resolution to load.
> This has several drawbacks:
>
> - This violates the content-presentation separation principle.
> - This does not allow for dynamically resized images, such as scale on
> hover.
> - This takes away freedom of the user & user agent.
>
> The alternative is both simpler and more efficient than the current
> implementation:
>
> 1. The server presents an array of different sizes of the same image.
> 2. The user agent calculates the optimal image size for current context.
>
> This would allow the user agent to consider such factors as pixel density,
> bandwidth-saving settings, lazy loading, and any other features, including
> the more advanced ones. For example, the same image can be present as a
> full-width banner and a thumbnail. The browser can load just one
> high-resolution image and resize it; both images; the thumbnail first, and
> load the larger image after (especially if it isn't a progressive JPEG).
>
> This gives freedom for the user, who can specify their preferred
> interaction behavior with websites; upholds the idea of trust between the
> user and the server; and gives the front-end developers the freedom to work
> on more important features while leaving more to automation (and the user).
> Finally, if necessary, the `sizes` attribute can be used to further tweak
> the default behavior if the developers see it necessary.
>
> I can see a potential difficulty with this implementation, whereas to
> calculating the displayed image size in the first place requires loading
> the appropriate (or another) image first. This is avoidable by specifying a
> default image size, for instance as an optional third argument within
> `srcset`.
>
> This behavior could be easily implemented even with the current spec's
> framework. If the browsers were made to consider the actual image size
> instead of the screen width, all of the current implementations of `srcset`
> + `sizes` would retain current functionality at worst, and improve their
> performance at best. Going forward, the developers would not need to
> implement the `sizes`  attribute at all unless needed for a specific
> use-case.
>
> I could hardly find any material on the subject. Why is the current
> implementation such as it is? What are the drawbacks to what I am
> describing? Perhaps what we have now is a sort of a transitional period?
>
> PS: I see that this mailing list is not active. Is there a better place
> for this discussion? A particular Community Group?
>