Many words have already been spilled about the sheer beauty of the screen on the new iPad; whilst they seem hyperbolic, they are pretty spot on: it’s amazing. The best screen I’ve ever seen, easily.

In fact, it’s too good.

When the iPhone 4 came out I – and many others – started shunning any apps that hadn’t been “retina-ized”, as they looked pretty rubbish in comparison with everything else on the device. The web got away ok on this front, as the screen was pretty small and most sites were being scaled down anyway (in fact, the retina display really helped with the readability of scaled down sites).

Now, however, in comes the retina iPad and it doesn’t have that luxury of scaling down sites; it has a big enough display to show sites at full resolution, and in fact the web is one of the primary uses of the device.

And now, all of a sudden, it looks rubbish.

Text is fine, as is anything using CSS3 properties like border-radius, but any and all graphics look pretty horrible and stand out like a sore thumb in their near 8bit pixel-y glory.

Fortunately it’s pretty easy to send retina-display devices (currently only iPads, iPods and iPhones, as there are no Android pixel-double devices I’m aware of) different graphics using a CSS media query thusly:

@media screen and (-webkit-min-device-pixel-ratio: 2) { // styles go here }

Combined with the background-size (to scale the images by half) and some double size graphics it’s not to hard, if a little bit of a pain if you’ve got a graphics heavy site. There’s also the obvious downside that you’ve got to send double size graphics, which will mean they take up a lot more bandwidth but that can’t really be helped.

For inline images – rather then CSS based graphics – it’s slightly trickier; you could just serve everyone double size graphics and scale them down to the right size, but that would have pretty significant bandwidth implications (although has the plus side of being easy to implement). Alternatively, you could use a bit of JS to switch graphics resources on the fly in a similar way to this Responsive Images script does.

In a similar fashion I’m hoping that the retina iPad is finally the kick up the backside that eMagazine creators need to switch away from packaging up a series of images as a “magazine”; they’re already huge and doubling them in size to make them retina compatible will drive most over the 1GB/issue mark, which would be ridiculous. Here’s hoping they switch to something HTML based so the file sizes get significantly smaller, not even bigger…


“there are no Android pixel-double devices I’m aware of”

There’s more than a few (depends on what you mean by double density). If you’re just talking about things that match the iPhone4, there’s 3 or 4 (the Galaxy Nexus is almost exactly the same with a bigger screen giving you even more pixels). If you’re talking about things that not horrible (i.e. better than the iPhone3, over 200dpi?), that’s most of the major phones released in the last 2 years.

Unfortunately, people design for the mobile web like they designed for desktop sites 10 years ago. i.e. they design for one device and screen only. Regardless of resolution, everyone has to scale web pages to 320px wide in order to not render the web like crap.

Mar 18, 09:11 PM

Is does appear you’re correct – whilst I was aware there were plenty of Android devices with hi-res screens, I didn’t realise there was a similar scheme for pixel scaling. Although it does appear that the scailing factor is often 1.5x which is obviously a bit less convienient then 2x.

Mar 18, 10:50 PM

If you want to get your current website supporting Retina etc, you could try and see whether it works for your use case. It has a JS version to detect high DPI devices like the iPad, and automatically creates lower resolution images from your existing high-res ones; serving the correct sizes to each device. The nice thing is you can apply that solution to existing sites and content. Caveat: It means you can’t use CDN’s for your assets.

PS: there are no perfect solutions to the inline image problem, it is incredibly tricky and “simply swapping with JS” doesn’t work because modern browsers always request the original in addition to the swapped out attribute. I.e., it’s worse than doing nothing.

Mar 19, 12:25 PM

“… that eMagazine creators need to switch away from packaging up a series of images as a “magazine”;”
Be sure, we have to! But it is quite difficult to find the right program for it. Especially when you can not produce everything in HTML.

Greetings from Berlin!

Mar 21, 01:33 AM

Comments are turned off for this article.