Comment by phiresky | Hacker News Reader

Comment by phiresky | Hacker News Reader

I never understood why the `sizes` attribute has to be so complicated. Why do I have to decide on which image to choose based on the display size instead of it automatically choosing the best image based on the size the image is displayed as?

It makes it impossible to choose the "correct" image without using JS if the amount of space the image will take up of the viewport is determined in some relative manner (i.e. basically always).

For example, If I have a container with width: 10em, and then in there an image with width: 50%. I want to just e.g. specify 3 alternative images with widths 200px, 400px, 800px. The browser knows the exact pixel size the image will actually be, so why can't it just choose the best one? Why do I have to specify which one to use based on the viewport width instead of the actual image width? It's impossible to calculate that unless your image is a known fixed ratio of the viewport or by asking the layout engine for the computed width (with JS).

There's an answer about this being impossible by one of the spec authors here: https://stackoverflow.com/questions/38684928/correct-sizes-f... But it doesn't explain at all why it was done this way, I don't even know when I would ever prefer to specify the chosen image in the way the spec currently requires.

The browser doesn’t know the size at which the image will be rendered on the page until it has downloaded and parsed all the relevant CSS and JavaScript files. Shortly after the browser downloads the HTML, it requests CSS and JavaScript. But before the CSS and JavaScript is done loading, the browser starts downloading images. The only thing that the browser does know is the size of the viewport. If we give sizes based on screen width then the browser will know which image to use. The width doesn’t have to be expressed as a viewport width unit though. It can be any length including absolute and relative length. You can even use CSS calc() to do things like auto-calculate margins dynamically.

For your example I believe it would be done like so:

<img src="cat-200.jpg" alt="cat" srcset="cat-200.jpg 200w, cat-400.jpg 400w, cat-800.jpg 800w" sizes="5em">

This page explains responsive images further: https://cloudfour.com/thinks/responsive-images-101-part-5-si...

> If I have a container with width: 10em, and then in there an image with width: 50%. I want to just e.g. specify 3 alternative images with widths 200px, 400px, 800px.

Basically, you want container queries, something long desired. It’s actively in the works but it’s first going to be for elements. Once that is working, it can inform how to implement it for responsive images.

Container queries are a red herring here; they don’t change anything at all. The question being asked here is “why doesn’t it just use the image’s size?” and the real answer to that is that you don’t want to wait for the CSS to all be loaded before fetching any images at all—that’d be a pessimisation, not an optimisation. Hence the sizes attribute cares about viewport sizes, and always will do. Container queries will almost certainly never get involved in this, because, along with the rest of CSS, they’re evaluated after image loading begins.

You misunderstand me; one will not use container queries to load images responsively, responsive image standards will be changed in ways that are informed by how container queries are implemented.

I did misunderstand you at least partially, but my point stands: container queries are part of CSS and layout, and I think it’s very unlikely that they will yield any new approach for responsive image source specifications, because making it work would require shifting waaaaay too much stuff into presentational HTML. What the sizes attribute covers is bad enough in this regard, but it’s at least straightforward to implement in an isolated fashion.

Reply on news.ycombinator.com