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.