[ned]

The idea of compound images is really interesting, although it would require an extra HTTP request to fetch the hight-DPI portion of the image. But maybe less of a problem over SPDY?

The idea truncatable bitstreams is fascinating too. I'm not well versed in networking, but wouldn't the latency of a mobile network kill the benefit of this technique? e.g, by the time the server receives the "connection closed" signal, a large part of the extra data would have been sent, no?

[archgrove]

It would need an extra HTTP request, yes. In practice for the PNG solution, one would be better off with sending the DPI in the request headers, so that the "correct" image is the only one sent.

For JPEG 2000, the network characteristics are important, but I don't think it would be too bad on a mobile network. Low DPI devices might get a bit "too much", but it wouldn't be a problem - they can just throw it out (or incorporate more detail).

[jentulman]

Headers do seem the best place for a non vendor specific standard to be set. I'd love to see something like

viewport-dpi - the dpi viewport-max - the maximum possible pixel dimension and possibly viewport-current - the pixel dimensions at the time of the request

Decent responsive design should deal with the differing viewport sizes, but it might be nice to get a hint before delivering your page what direction to weight that response in.

[nextparadigms]

Would this work better over WebP?

[dwnoiz]

Check this way of doing it to avoid extra http requests. http://www.archer-group.com/2012/development/javascript-jque...

[caseyohara]

That is certainly the ideal way to reduce the HTTP requests. The problem with this implementation is clear: without a 'src' attribute on your images, if your script fails then your site suddenly has no images at all. Not to mention the overhead of manually modifying all of your existing markup.

Our goal with retina.js was to make it zero-config: no markup changes, no extra element attributes or flags.