That was actually my inspiration for this. Added support for stuffing multiple different assets in a single svg file, and did it with JS to avoid redundant image requests and keep it easy to use.
Vector SVG graphics absolutely do work great on retina displays. This is for serving raster retina images, and the JavaScript enables you to request only the resolution appropriate for each client.
The only problem I've got with this is that the JS image generator is run for every image on every svg load. If anyone can think of a way to only run it for the target image, I'm all ears; still struggling with it for now.
I think it's definitely time we have a replacement for copyright, given the irrelevance of copying nowadays, though "Publish Right" is likely a better term than "Broadcast Right", since the main issue is the commercial distribution arrangements for protected works. If some agreement can be found, after a certain date, copyright should stop being issued and the new right issued instead. Now we just need to figure out what that will be.
I guess I set up my proposal the way I did so that authors could explicitly flag assets as being available or unavailable in 2x in the most convenient way conceivable to me, because it would add inefficiency to force a choice between assuming all assets are available in 2x and that none are, as some requests will fail if they're not all available in 2x. I will mention that for my proposal, if you want to assume all assets are available in 2x, the extent of the work for authors would be to add '<meta image-scaling={2:"@2x"} />' to the page. It is potentially more work than HAIR, but I figured it would pay off with server resource efficiency, accessibility to authors, and powerful flexibility.
That said, I could totally get on board with HAIR, assuming my concerns are unfounded (which is likely). How does that system affect server capacity and performance? Is there a significant performance penalty for having the server determine whether each asset is actually available in 2x or not before fulfilling the client's request? Is this information which would automatically be cached, and thus not have a significant impact? Or will each image request have an additional operation to perform?
Also, does this system force you to have your 1x and 2x assets share the same exact filename? In the example, are the 1x images in the 'img' directory, and the 2x in 'image' with the same filename? I'm sorry if my confusion is making me ask the wrong questions; maybe evidence of the challenge of explaining this system to clueless people like me.
[Upon further review, it looks like an img src link to '/img/bob/' would load the 'index.jpg' file from inside the 'bob' directory by default, and then your system would have it load the 'dpr=2.jpg' file if the client wants that. So this imposes even more stringent file naming and organizing restrictions than I had in mind, and it works nothing like what I thought upon first glance (never knew you could even link to a directory for an image asset, and have it load index.jpg, though it does make sense). I am embarrassed to admit that I'm not completely sure where I'd even put those parameters, though I assume it would be in httpd.conf for apache, or maybe .htaccess otherwise. Also, does this require a separate entry for each image on the site?]
And what about the performance penalty for the server to determine 2x availability for sites where only a fraction of images are available at 2x res?
I'm also not sure I fully understand how we clue the server in on where to look for the 2x version of a 1x asset. In the examples given, do the 2x versions have the same filenames as the 1x versions, but they're in the 'image' directory rather than 'img'? Seems like a significant limitation to force different assets to share the same filename, if that's what's going on here.
I don't understand how that resolves the issue. Let's say you have two img elements on your page, linking to their respective 1x image assets, and you have a 2x version of the image available for the first but not the second. You indicate 2x availability in your HTTP header, and a client which supports this protocol wishes to display 2x images.
Does the client specifically request 2x image file paths for both images, and when the second one fails, as no 2x version exists, the client makes another request for the 1x version, or does it simply fail to load the image?
Or does the client request the 1x asset like usual, and when the server determines that one is unavailable in 2x res, it sends the 1x transparently? If that's the case, do we not care about the server using resources determining availability of individual 2x assets because it's insignificant? And could the client easily choose to request 1x assets rather than 2x in a non-hackish way even if it does support 2x resolution (maybe it's concerned about bandwidth)?
It seems inflexible and potentially inefficient though. What if you have 2x assets available for some images but not others? Will the client be making two requests in all those cases? Or will it simply break?
With the solution I propose, it seems like the server could be blissfully dumb, and the client could be smart and choose whether to request 2x images if the page author indicates they're available. I don't see the advantage in this regard.
Why is this information put in the HTTP headers rather than the HTML for the page in question? It just seems like a relatively obscure place to hide what's bound to be a common bit of functionality; not the most noob-friendly solution.
I submitted a different potential solution to whatwg forums and a few relevant mailing lists, without much significant feedback, using meta tags to indicate availability of 2x image assets. It does seem more practical to me from the point of view of an author, but maybe I'm missing something important:
http://thepenzone.com/svg-image/