[dorianj]

This is needlessly complex. I really don't see pixel ratios of anything more than 2x being useful. Having two versions of assets is painful enough.

The apple convention, of having images with "@2x" appended, works quite well. The server could look for a http header indicating DPI and serve accordingly. This gives the developer to provide either one single HiDPI that's served to all clients, or separate files for HiDPI and normal resolution.

[WiseWeasel]

It is short-sighted to assume that 2x will be the limit of high-resolution images. If we're making browser developers add support for this, we might as well have it be at least somewhat future-proof.

[pornel]

Meaning of "1x" has changed from 72dpi to 100-130dpi over time.

It's not unreasonable to assume that same will happen with "2x" as screen densities gradually improve, and over time it will shift from 220dpi to 300dpi-400dpi (for desktop viewing distances).

Density doesn't need to improve indefinitely, it just needs to cross the "retina" threshold (which arguably 2x does already).

[skeltoac]

I mistakenly included a great deal of peripheral detail in the first draft. It's not as complex as all that. It is sufficient to provide only 2 versions of each asset: the 1:1 default and a higher-res version, whether it's 2x or 15MP.

You mention an HTTP header indicating DPI. Sending device pixel ratio is already a major part of the HAIR proposal; see Example 2. If that's all that got added to browsers and servers, it would eliminate most of the app-level solutions out there.

[greggman]

There are already ratios of 1.5, 1.33 and 2.25 in the wild.

See Android

[WiseWeasel]

Wait, are you saying there's a version of Android somewhere that ships with a web browser which actually specifies its device pixel ratio as a non-integer? I am dubious, since I assume that would force rough anti-aliasing on everything and look like crap.