@Janne there is nothing in the request headers that can tell you what the resolution of the device will be. :-(

@ian Yes, mediaqueries will help with CSS images. Some of these images could have been better handles as CSS. Or font-face declarations. Some are actual content that should be treated in the content of the page as an img tag. For images that should use the img tag, there are no great solutions:
http://cloudfour.com/responsive-imgs-part-2/

Avi is correct it should be built into the img tag, the same way lowsrc was used for slower connections.

There is an existing technology ALREADY designed for this called media queries, whoever is doing the heavy lifting here is specifically targeting iPads and shoud not be looking to this as a foolproof method of serving up retina images for the web.

See here for a better solution. http://blog.iwalt.com/2010/06/targeting-the-iphone-4-retina-display-with-css3-media-queries.html

This is such an obvious solution, though, that there must be some fallacy I didn’t think of…

1. We had a mobile version until last week. We got infected by the current wordpress malware that is going around (http://blog.sucuri.net/2012/03/rr-nu-malware-campain-more-details.html). Last week there was no specific vector that the attack was coming from. Ergo, we turned off any plugins that were unnecessary including the one that did theme switching to our mobile theme.

2. The theme switching plugin is unnecessary because we’re nearing completion of a new responsive site and plan to launch it in the coming days. No need to invest more time in the current site other than to clean up the malware crap.

3. As the saying goes, the cobbler’s children have no shoes. We’ve spent on our time our client projects and not on our own site. We’re keenly aware of its short comings.

Finally, thank you for putting us in our place. It’s nice to know you’re looking out for us. Have a pleasant day!

Brett: On the Globe site, we prototyped with a php/htaccess setup that simply split a comma-separated URL into files and concatenated/minified/gzipped the output. For JS, we loaded only about 5kb up front, which contained feature tests and media query polyfills, from there, we dynamically loaded all the rest of the JS and Ads, so even if they were a little heavier than we’d wanted, they at least would not block an already-usable page from being used.

In production, The Globe team rebuilt our prototype in their own preferred tech – the solution is easy enough to reproduce, and this doesn’t include the minify part, but you might check out “CSS and Javascript Combinator 0.5 by Niels Leenheer” to help you get the gears churning: