Hacker News new | ask | show | jobs
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.

2 comments

I think you completely misunderstood.

> 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:

    <img src="you.jpg" progressive>
The obvious advantage is that if the window size changes, the browser only has to fetch the missing data, not a whole new file.
I think what they were descrbing was more like this: A JPEG uses a Discrete Cosine Transform and then throws away the lower power (higher frequency) values, but does it in a fixed way(blocking). If you re-order the data such that you get all the blocks dc frequency first (rather than all the frequencies for block 0 first) you can stop at any time and you'll have the resolution you "paid" for - ie, your bandwidth is all used for resolution. It's not a bad idea, although I suspect the reason this isn't done is because you don't really need to decided between a 72kb and 73kb image, and in reality there's more to different resolution images than just saving fewere bits (read: interpolation techniques)