The problem with providing higher resolution images on websites is several problems, actually.
In all of these examples, let's assume that I want the image element to be 320px by 240px. My source image is 3200x2400 (to make the math easier).
First thing I'll note is that the HTML standard defines the inch, and then defines 1 pixel as 1/96 of an inch. However, in practice, most web browsers go the other way around and define an inch as 96 pixels. HiDPI Apple browsers define an inch as 192 pixels (upscaling if elements don't have enough information), and on IE on Windows, an inch can be 96, 120 (Win7 1.25x), 134.4 (Win8 1.4x), 144 (Win7 1.5x), or 172.8 (Win8 1.8x) pixels by default (with some registry hacking, you can get more settings, but those are the defaults).
So, due to the ubiquity of 96 ppi browsers, common practice is to downscale the image to 320x240. This is the most efficient as far as bandwidth, but you can see the results.
Maximum compatibility including with future devices is had by uploading the 3200x2400 raw image to the server, and then using the width and height attributes to force the browser to draw the image at 320px by 240px (note that in this case, px is the HTML pixel, or 1/96 of what the browser thinks is an inch, and not an actual pixel). However, this greatly increases the bandwidth requirements for both server and client, as well as increasing the processing requirements for the client significantly.
The simplest way to do this is to stick a 640x480 image in there, and use the width and height attributes to restrict it to 320px by 240px. However, this still results in unnecessary information being sent to devices other than Apple retina devices, increasing bandwidth requirements, and it now provides a sub-optimal image for scaling on the Windows devices running their browsers at higher than 96 ppi.
Apple does things a little differently on their site (and there's a third-party implementation as well, Retina.js). They point the web page at a 320x240 image, so 96 ppi browsers get an appropriate image. Once the images have loaded, some JavaScript runs, checking for some Apple-specific extensions to the browser, and if present, changes the img elements to grab @2x - 640x480 in this case - versions. This works well for saving bandwidth when most users visit, but actually increases bandwidth use for HiDPI users. Worse, it's an Apple-specific implementation.
What I'd like to see is some standard, either in the user-agent, or in a new HTTP field, that specifies the browser's logical PPI. Then, the server could elect to serve an image that's appropriate, caching the common sizes, and using ImageMagick to generate uncommon sizes on demand (I believe MediaWiki already has support for the on-demand scaling for this method, but doing it via filename instead). A workaround for now would be to use JavaScript to detect the logical PPI, then set a cookie, and retrieve that cookie on every image load (or, use that cookie to determine what images to grab by filename, maybe, but I don't like special filenames for this due to the possibility of filename collisions), but that's clunky.
In any case, this won't actually affect me much - I'll be running at 96 logical ppi. That means my GAF is rather low for updating my own site. I'll wait until there's a vendor-neutral standard before I do that - Microsoft is going to want there to be a good standard for this that isn't so Apple-specific as the current one, so it will happen.
