How websites are adapting for the new iPad Retina display and other HiDPI screens

Following the launch of the new iPad there's been a lot of discussion about how, and where or even whether, websites should update to support the needs of HiDPI screens like Apple's Retina display. If users are going to be looking at websites on a Retina display iPad, and one day Retina display Macs, HiDPI Android and Windows displays, and other high density screens, having them look as good as possible is a definite concern.

The web, unfortunately, is nowhere near as controlled environment as the App Store.

Apple, of course, updated their iPad page for Retina display right away. According to Jason Grigsby of Cloud Four Blog, they're doing it with image_replacer.js.

What they’ve chose to do is load the regular images for the site and then if the device requesting the page is a new iPad with the retina display, they use javascript to replace the image with a high-res version of it.

The downside of this approach is that it's expensive, especially if you're serving all images this way, and the images are big. Bandwidth costs money and making every image 4 times larger (or more) means paying higher server bills. Serving a regular image and then switching to Retina is even more expensive, because you're serving both images to Retina devices. (Granted there aren't many yet, but their share will only grow.)

Phil Webb of Mobify.com offers several good pieces of advice, including prioritizing which images really need to be Retina (like product heroes), that text should be served as text and not images (we're in the age of TypeKit, after all!), creating double-sized images that are constrained by CSS width and height attributes, and the use of mobify.js.

Mobify can detect extra-high resolution displays, like the iPad 3 Retina and iPhone 4 and iPhone 4s with Retina, and serve them higher quality images.

And unlike many other techniques, like the approach Apple has taken to delivering Retina-quality images by just double-serving images, it lets you just serve the right image to the right device. So page performance is always as fast and snappy as possible.

On Quora, Read it Later developer Steve Streza promotes the use of CSS background images, the background-size attribute, sprite sheets, and media queries.

The big advantage here is that you can target specific screen scale factors with CSS, using a trick known as CSS media queries. This lets you specify entire CSS files, or parts of CSS files, to load for devices at 1x scale, at 2x scale, and other scales (as well as ranges of scales). This means that 1x scale devices are only loading 1x assets, and 2x scale devices are only loading 2x scale assets.

When it comes to photography on the web, Duncan Davidson, working with Streza, figured out that WebKit (the rendering engine behind Apple's Safari, Google's Chrome, webOS, BlackBerry's Torch, and other browsers) put limitations on image sizes that could conflict with serving Retina-calibur graphics. The workaround is to use progressive JPGs. But currently comes at a price.

Now, before you go reprocessing all your photos—and keep in mind that you can’t export progressive JPEG out of Lightroom or Aperture, so this isn’t an easy undertaking—please understand that this is just sorting out how to push a high DPI image to an iPad Retina display. Doing this well for more than a one-off example is going to take a lot more work, not the least of which is sorting out how to decide when to push a progressive JPEG at what size for the right client and bandwidth combinations.

So while it's early days and there are no clear standards for implementing cross-platform, cross-browser HiDPI graphics, there's a lot of experimentation being done. We consciously made the choice to use as much CSS as possible with our last iMore redesign, and I think that paid off. We've also replaced our previous, PNG background logo image with a 2x icon graphic and TypeKit text. We need to tweak it some more, but it already looks better on the new iPad. Likewise, we've used higher density Team iMore pictures in the sidebar for a while now, and are going to be rolling out more of them into the rest of the fairly static page elements.

If you're working on adding Retina/HiDPI support to your website, jump into our Iterate mobile design forum and let us know how you're doing it and how it's working.

You're living in fantasy land. Outside the U.S., the iPAD does not receive the same glory. Considering the billions of people in the world, and the extremely small number that have an iPAD with retina display (3 million... perhaps 11 million by end year) and you soon see that this is zero benefit for web designers to create retina display web sites... other than the odd few (super small number) who do so for the purpose of graphics and glory.

The same thing was said of 300dpi digital images for magazines. Then 600dpi. Then 1200dpi.
The same was said of 720p video. Then 1080p. Now 4K and 8K.
The same was said of 256kbps audio files, and lossless audio files.
The world changes. Technology improves.
That's not fantasy.
That's life.

I might've taken you more seriously if you could spell. 1080p can be retrieved in many more ways than just blu ray. Blu ray just means that you don't get the artifacts from compression. But they're not even that bad, you exaggerate like people did with the transition from analog music to digital

Detect browser id and serve a different view or make a method to determine which image to display in view based on browser id. Not hard to do using Rails. No JavaScript necessary (what if client has it turned off?!) and you won't be double loading images.

Thank you a lot for sharing this with all people you really know what you are talking about! Bookmarked. Kindly additionally seek advice from my website =). We may have a link exchange arrangement among us

hello there and thanks on your info ? I've certainly picked up anything new from right here. I did however experience a few technical points the use of this website, since I skilled to reload the site many instances previous to I could get it to load correctly. I have been pondering if your web host is OK? No longer that I'm complaining, but slow loading instances occasions will very frequently have an effect on your placement in google and could harm your high quality rating if ads and marketing with Adwords. Anyway I am including this RSS to my e-mail and can glance out for much extra of your respective interesting content. Make sure you update this once more very soon..

Android Applications are Linux support and are programmed in Java. The Linux OS is the most powerful and easiest to manage of all operating systems. Android code is written using Java syntax and the core android libraries include most of the features included the core Java APIs. The Java programming language with its superior GUI development capabilities provides a good platform for Android development. Although applications use Java syntax, they are not translated by a Java compiler into Java byte-code. They are compiled by the Android compiler into Dalvik byte-code. Versions of the Android SDK are available for Windows, Mac OS, and Linux. The SDK includes an emulator for all three environments. Android applications run on a virtual machine and so there is no particular advantage in one OS over another.

Hello, Neat post. There's an issue along with your website in internet explorer, could check this? IE still is the market chief and a big portion of other folks will miss your wonderful writing because of this problem.