How Apple Provides Retina-Display Images to New iPad Users

Details how Apple provides high-res images to new iPad users with fancy retina displays.

Don’t do it this way. It’s horribly inefficient and creates unnecessarily bloated pages, particularly as we are already well down the path of page bloat with JavaScript libraries, web fonts, images. These images are big, and they will slow down your page rendering if both sizes are downloading (and maybe more sizes if you have some mobile-optimized images in the mix).

The goal is to download only the image you need. It’s a plus that they check to make sure the image is there before they do the switch, particularly as they are still migrating some of their images. However, they could do that check/switch on the backend, where it wouldn’t require an HTTP request. My guess is that their code infrastructure makes this approach difficult.

It’s important to discuss how you want to support this new device because, as others have noted, some of these images look absolutely terrible on the new iPad.

One interesting approach to this problem is the proposed element, which looks something like this:

<picture alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">
	<source src="small.jpg">
	<source src="medium.jpg" media="(min-width: 400px)">
	<source src="large.jpg" media="(min-width: 800px)">

Using the pixel ratio/density sampling media queries (which are implemented in Gecko and Webkit), you can serve appropriate images to just about anybody. There’s even a polyfill that will let you start using this right now, with impressive browser support (albeit requiring much sketchier markup).

The downside, of course, is that there is no standard for this, and the standards-making bodies might go another direction. True browser support for the element without the polyfill might never happen. (Worth noting that you can serve retina-appropriate background images (or values to the content property in pseudo-elements) today using the aforementioned media queries.)

A point in its favor is that it builds off existing element structures that are quite popular with folks and already have media support (VIDEO and AUDIO). There is significant interest in finding an HTML-based solution, and this is one of the strongest proposals to date. However, even if it’s not PICTURE, it’ll be something in HTML.

Other approaches that have been proposed are:

  • altering the role of longdesc to point to another image src. It’s value is a URI, so it’s not too much of a stretch to use it to point to a different image. Isn’t backwards compatible, but since it’s so seldom used, it could be modified.
  • adding media support to IMG (unlikely since you still need a way to determine which one to show)
  • adding media support to OBJECT (already supports images and multiple images, could work in combination with media support on IMG)

OBJECT+IMG is the strongest contender since both of these elements already exist and have fallback mechanisms. It’ll be interesting to see how it shakes out.