How to make your web content look stunning on the iPhone 4's new Retina display

An image showing the superior detail in using high-resolution web images for the iPhone 4 Retina display

The moment you first lay eyes on the iPhone 4's new Retina display, you are ruined. No other display will ever make you happy. Not unless it, too, is a Retina display. You start seeing pixels everywhere. My beloved MacBook Pro's screen? Pixels. The iPad I bought a few months ago and couldn't leave aside? Pixels.

Retina changes everything

The iPhone 4 really does change everything again and not just for phones. By introducing the Retina display, Apple has just changed the rules of the game. Make no mistake, this is as fundamental a shift as the move from black and white to color TV. I now want Retina displays on my next iPad and my next MacBook Pro (and will happily pay a premium for it). Whether or not Apple has the technology to meet the expectations it has now created with the Retina display on its other products is another issue (i.e., does the technology exist to manufacture a 326ppi 15" retina display for a MacBook Pro?)

With the introduction of the Retina display, Apple has guaranteed the following three things:

  1. Vectors will play a central role in any graphic production pipeline.
  2. You basically have to design liquid interfaces (and interface elements) for your apps.
  3. You won't be able to get away with the levels of image compression you've been using so far.

Basically, if you want your applications and web sites to look beautiful on the iPhone 4's new retina screen, you're going to have to create high-resolution versions of your bitmaps and/or use vectors. Resolution independence is here today and it is here to stay.

What about images in web pages?

While version 4 of the iPhone SDK handles much of the hassle of working with two versions of every bitmap for you by automatically loading the right image if you adhere to the simple naming convention of adding @2x to the ends of your image names, no such automagic handling of images exists for images in web pages. I'd been meaning to look into this since I got my iPhone 4 last week and was happy to see that Walt Dickinson beat me to it with his article on Targeting the iPhone 4 Retina Display with CSS3 Media Queries in which he draws on Dave Hyatt's post on high DPI web sites, John Gruber's Why 960x640 post, and the Safari Web Content Guide to suggest the use of device-pixel-ratio CSS3 media query to serve high-resolution images to devices with high-DPI screens:

Then, in the Retina-specific CSS, he loads in 32x32 icons as background images and specifies their dimensions in CSS pixels as 16x16 using the background-size CSS property.

Demo

I put together a quick demo using the same technique that you can test out. It uses the lovely Smashing Royal Icon Set by Artua.com to embed 64x64 and 128x128 actual pixel size icons for display at 64x64 CSS pixel size.

Download the source (.zip; 74KB).

CSS media queries and background images are all well and good, but what about other visual assets such as images embedded on a web site via the img tag? Or videos?

A call for native browser support for high-DPI image and video substitution

I'd like to suggest that browsers adopt the same naming convention that Cocoa Touch uses to find and load high-DPI versions of image and video assets. That is, if I embed an image using the following code…

A beautiful rose

… it should load in flower.jpg when the device-pixel-ratio is 1 but it should attempt to find an image called flower@2x.jpg at the same relative path if device-pixel-ratio is 2 (and so on, for higher pixel-ratios), falling back to the original graphic if it can't find a high-resolution version.

(And the same convention could be used to load video assets.)

Update: Magne Andersson pointed out in the comments (and I agree) that sending two requests for every image asset would not be ideal. However, it would be easy to work around this by introducing a new HTML meta tag that tells the browser whether or not high-resolution images are available. The browser then only tries to load high-resolution images if the meta tag is present and if it detects that it is running on a high-DPI screen.

How to optimize for high-DPI screens today

Since browsers do not currently have this sort of automatic support for loading high-resolution versions of image and video assets, how can we detect that the site is being displayed on a high-DPI screen and load in high-resolution assets? The obvious way is to use a combination of CSS media queries and JavaScript:

  1. Use the device-pixel-ratio CSS query to load in a high-DPI CSS file,
  2. Set some CSS property to a unique value (to use as a flag),
  3. Check that value in JavaScript and substitute high-resolution image/video assets accordingly.

Don't forget about SVG

SVG has been the unloved step-child of the web ever since I can remember. However, it has really begun interest me now that we're moving to creating resolution-independent designs. (That's why I'm so happy that I have the chance to catch Doug Schepers's talk on SVG at tonight's SkillSwap after missing it during WebDirections @media.) If you, too, have been ignoring it, now might be a good time to take another look.

Why native iPhone app developers should care

Most native iPhone applications are – to some degree – hybrid apps and use the UIWebView WebKit control to embed HTML, CSS, and JavaScript content. Some native apps – such as those wrapped by PhoneGap, are almost entirely created with web technologies. Regardless of where on this spectrum your app falls, you will probably find yourself having to support high-DPI images in web content. Not only that, but UIWebView renders SVG so you could consider using it to keep parts of your interface as vectors without having to write custom drawing code.

The iPhone 4's Retina display really does change everything. The sooner you start thinking about (and practicing) resolution-independent design, the sooner you can start to take advantage of this beautiful new screen and the other high-DPI screens that will, no doubt, be following its lead.

Comments