Now that things around iPad fever are quieting down a little bit, people are realizing the implications of the new iPad. I’ve seen one only briefly, but it’s clear it’s the way things are going. There is still one big, elephant-in-the-room question: How do we deal with serving images on web pages to high resolution displays?

(Note: If you’re looking to soup your site up with Retina-level images, you should look at Retina Display for Mobile Web and How Apple.com Will Server Retina Images to the New iPads. This post is about what browsers should do.)

The current solutions for serving high-resolution images don’t scale (zing!) and are pretty crappy. They muck up your site’s JavaScript and CSS. Whether or not to load Retina images should be a decision the browser makes, not one the JavaScript makes.

Currently, Apple.com will do the following for Retina images using JavaScript:

  • Load and render the page using normal images.
  • Go through and see if any images can be upgraded to Retina.
  • Shoot off HEAD requests to see if the images exist at the specified location.
  • Pull down the new images and put them into their proper places.

That’s the best way you can do it right now. In the future, here’s how browsers should handle high resolution assets:

* Examine a page’s HTML for any image tags.

  • If the current device supports high resolution assets, fire off a HEAD request for both the image path (e.g., “/image.png”) and it’s high-resolution counterpart, “/image-2x.png”.
  • Download the proper image depending on availability.

The “-2x” suffix will just be the not-so-secret handshake for serving up high resolution assets. When we get even higher resolution screens— “-4x”!—we can fold those in easily without changing code on our sites.

Using this solution, it’s simply up to site owners to put “-2x” assets in their proper places. If they don’t, normal images will be used. The web doesn’t break and we don’t relegate pixel density decisions to JavaScript. It’s nice to have JavaScript know about connectivity statuses, but the browser should decide if it’s appropriate (i.e. you have enough bandwidth and you’re on a Retina device) if it’s going to make the request for -2x assets.

Update: My God, what have I done. Angus, Chris and Dondi pointed out this morning that I was having trouble seeing the forest through the trees. What I wrote earlier was wrong. Not like “Oh, that could work” wrong. Just wrong.

Here’s how it should work:

  • Each browser includes a special header, like “X-Pixel-Density-Ratio”, in each image request. The server returns the proper image.

Boom. Done. Fewer requests made. Doing this requires a bit more knowledge of how your web server serves out images. Chances are you’ll need a smarter-than-your-average CDN. Luckly, Chris’ company Imgix is already working on such a thing. Keep an eye on them.

In the meantime, we just need someone to do a proof-of-concept build in Gecko or Webkit assuming one hasn’t already been done.

You can also follow me on Twitter.

(The ideas for this blog post came from a few conversations I had with Anthony Volodkin and Allan Grinshtein. Correction credits to Angus McIntyre, Chris Zacharias and Dondi.)