> using some kind of Accept header.

That would be way saner, the problem is that it seems no one wants wants to touch HTTP. Browser vendors work under the assumption that whatever feature they implement, it only has a chance of being adopted if it can be hacked in other browsers with javascript shims.

The stupid part about that logic re:images is that you get graceful degradation for free in systems that don't implement the additional Accept header.

It's not stupid. From an academic perspective, sure it works either way. From a business perspective, you have to support the full feature set on a given set of browsers, and you're not going to waste time on a solution that only covers 80% of your required browsers when you can write one codebase that covers all of your browsers.

Or have a progressive image format. Wherein the smallest/lowest quality image is at the front of the file and is enhanced by loading more data of the same file.

It should be up to the browser and the image file format to determine the best option.

JPEG2000 had awesome option of having progressive quality. During compression user could specify number of quality years, with each layer having specific compression ratios. Browser could download a chunk of JPEG2000 and render it, and depending on bandwidth available the browser would keep downloading and improving image quality.

Both Jasper support this (ilyrrates) and OpenJpeg (-r and -q) support this functionality.

I really wish the open-source JP2 situation was better. OpenJPEG is looking good but it's still in need of some performance work – which is a real shame since, as you pointed out, it'd be perfect for responsive imaging - just use HTTP byte ranges and it'd work with most proxies and caches, too.

That's not so great for high-latency networks (like most cellular networks). If you use range requests, you add round trips. If you cancel the load partway, you're too late because your pipe is already filled with bits you don't need.

You could avoid that with a simple optimization where the page could indicate the byte ranges for a tile level. Suppose something like this worked:

    <picture>
      <source srcset="foo.jp2 100w 100h range=1-<first layer>">
      <source srcset="foo.jp2 500w 500h range=1-<middle>">
      <source srcset="foo.jp2 1000w 1000h">
    </picture>

That'd avoid the need to a round trip at all and it'd also be a huge improvement for caches which support HTTP range correctly since it'd be a single resource rather than multiple different URLs. It'd also allow browsers to start making decisions like selectively preloading more of an image which the user is likely to zoom, etc. although some of that would come simply from a good progressive JP2 implementation.

Manually specifying different HTTP ranges of the same resource is more verbose, more error-prone and more confusing than just specifying different resources. Other than that, I guess it would work.

> more verbose, more error-prone and more confusing than just specifying different resources

That's largely opinion: are byte ranges really better than having to maintain clusters of related images? Any serious site already has to deal with things like cache invalidation when a source file changes and by the scale of things which sites do for performance this is certainly no worse than, say, JavaScript/CSS minification or UA sniffing.

I'm not a network engineer. But perhaps this wouldn't be a problem once `SDPY` is popularized.

It would be less painful but still a problem: SPDY / HTTP/2.0 allows you to send more traffic over a connection but they can't do much for round-trip latency if you need to do something like ask what sizes of an image are available. That's particularly painful on cellular networks with a delay measured in hundreds of milliseconds – SPDY's ability to ship many things in parallel would only come into play after the browser knew which resources to request.

There was, long ago, the lowsrc attribute, with a similar intent. It was deprecated.

That would certainly be the cleanest solution, but I think we rely on so many old servers, CDNs, shared hosts etc that implementors (rightfully) worry that it would hurt uptake.

On the other hand, could that work without server-side code? If the logic is all done in the browser, you don't need support in your web server and you can still load pages straight from disk.

All it would take is some internal rewrite on the server, some directive to serve "lolcat_300dpi.jpg" when the client requests "/media/lolcat.jpg" with an accept header like "image/jpeg;dpi=300".

It would be way more flexible and even easier to implement, since you don't have to revisit all your markup.

If I may inject a shameless plug, this is exactly what http://www.pixtulate.com does to serve up responsive images and hi/low res images depending on screen resolution.

Yes, unfortunately we have to rely on a small client side javascript to detect your client's properties but the solution allows you to both upload and reference one and the same image and URL regardless of client and we'll scale, re-sample and even crop on the fly and cache the formatted image for future requests. We are trying to provide an experience as seamless as HTTP content negotiation.

Theoretically, yes, but that means you need a pretty complicated setup to serve static assets.

Also, this solution can be built into a Javascript shim for older browsers, something header-based would be much harder to do as a shim.

> Theoretically, yes, but that means you need a pretty complicated setup to serve static assets.

Why? There's no difference on the server side, you would have multiple versions of the same file anyway. You're just exchanging the responsibility of getting the right file from the markup to responding with the right file on the server (which is way easier to keep consistent, IMO).

The way I see it, keeping it in the markup makes it more straightforward to debug. If it's server-side, all of our developers need direct access to the asset server as soon as there are content negotiation issues. If it's client-side, we can share a highly-available asset server and each developer has their code sandboxed.

In an ideal world, it would be server side. But it would easily mean twice as much work to get there.

I wish people would spend a few hundred hours thinking about, discussing and implementing a feature, before posting critique opinions.