|
|
|
|
|
by SahAssar
2146 days ago
|
|
That argument ignores everything that new formats and container formats can allow for. And if the argument is to put older formats "first" then you need to download older formats first to get the features of new formats and need to figure out the order of competing modern formats (like JPEGXR vs JPEG2000 vs WEBP). This is basically a solved problem when people use mime types properly for formats. For sizes we'd need a similar way to mime types to ask for a size, html solves this for images with srcset but I'd rather it be within the transport mechanism rather than in the markup. Requesting an image should be requesting a image, not a specific representation of that image. The representation should be part of the content negotiation that is already a part of the protocol. |
|
> Requesting an image should be requesting a image, not a specific representation of that image.
This is exactly what I’m saying. The image is one, it’s the browser that decides how much of it to load.
It’s the current picture/srcset-based situation that is “a specific representation of that image”
> For sizes we'd need a similar way to mime types to ask for a size
Now that is complicating things. Suddenly the server has to produce/return different resources based on a header. The solution I described could be delivered by any dumb HTTP2 server, without preprocessing.
Technically what I’m describing is already possible with any progressive format like JPEG; The only missing part is that the browser should pause/resume the loading as it sees fit.
All I want for Christmas is:
The obvious advantage is that if the window size changes, the browser only has to fetch the missing data, not a whole new file.