The new iPad and resolution independence

Today, the New iPad hits stores here in Sweden, one week after its US launch. The big news is of course the new retina display with a screen resolution double that of the iPad 2. This is a good time for web designers to take a minute to think about how to handle this new screen landscape.

Hannes Lilljequist
SthlmConnection
6 min readMay 15, 2017

--

Note: This article was originally published on March 23 2012 on the SthlmConnection company blog. A lot of the general information is still valid, but the specifics are probably out-of-date.

“Retina screen”, as you probably know, is Apple’s name for the high resolution displays they have been using on the iPhone 4 and 4S for the last couple of years. With the new iPad launch, the tablet market too has seen its first real high resolution display.

Screens are generally becoming more and more high density, but Apple took a new approach in this case. Instead of incrementally increasing the resolution with each release of a new device, they decided to simply double the resolution of iPhone 3x when releasing iPhone 4, from 320x480 to 640x960. The result was a display with a pixel density of 326 ppi — which is way higher than seen in any consumer display before it.

The idea with the 1:2 ratio between the previous and the new version was that existing applications would run with doubled pixels — thus avoiding all sorts of potential migration headaches. In fact, on Apple’s retina screen devices, a pixel is no longer equal to a physical dot on the screen. It has become an arbitrary measurement which represents 2x2 hardware pixels, which seems silly in a way, but also makes sense for backward compatibility.

There is no standard around this “double pixel” approach outside of the iOS universe, but there are also high-resolution Android phones and tablets on the way, and Android does have a new screens support API, which defines the concept of Density-independent pixels (dp). This is similar to Apple’s approach, except that it allows the device to define an arbitrary ratio between the physical pixels and the dp — it doesn’t assume that it’s 1:2.

A new measurement

So how does a common web developer deal with this situation? The Pixel has been the lowest common denominator in web design since forever, only partially being challenged by ems and percentages — and now these people are ruining it all. Or are they?

However you look at it, the old way of using screen pixels as measurement is flawed. With increasing screen densities, a single pixel becomes less and less important, and differences in resolution between devices make pixels a poor measurement standard. We need a new unit for screen designs — so why not follow Apple’s lead and settle on an abstracted pixel unit for measurements, and let devices decide how big they should be rendered?

New content requirements

Vector graphics, CSS based shapes and type all handle this situation very well, since they are pixel and resolution independent. This is a strong case for using vector graphics, modern CSS techniques and web type as much as possible.

Pixel graphics on the other hand is the big hurdle. While text and vector graphics will look nice and clear, pixel images will look blurry and pixelated by comparison. Screen graphics is most commonly created as pixel images with a 1:1 relationship to the screen resolution that they are targeting. Apple’s solution for native iOS apps is a system where app developers create two copies of each image: one for standard displays (like those on iPhone 3x and iPad 1–2) and one twice the size for retina displays.

Regardless of how your images are rendered today and in the near future, it’s a good idea to keep high-res or vector based copies of all images you publish. If you use a publishing platform that automatically scales your images to the proper dimensions (like Drupal does), you might as well make the uploaded images quite large so you have the option to increase the rendered image sizes later.

Now, let’s take a look at a couple of different techniques web developers can use to leverage the high resolution of the retina display.

Increase image resolution

Let’s start with regular <img> tags. As you know, they have width and height attributes, and we have been taught that these should be the same as the pixel dimensions of the image – but they don't have to be. Make the image double the size of the target dimensions (but specify the attributes the way you normally would), and voilà – your image is retina-ready.

Another way of doing this is to omit the width/height attributes, and specify the size with CSS properties instead. The benefit of this is that you can use percentage values instead of pixels, which is important when doing responsive web design. Another benefit is that you only have to define one of the dimensions (usually the width) and the browser will calculate the other dimension for you.

With either of these approaches, the actual pixel size of the image is separate from the displayed dimensions. You can make it as large as you want, but you also have to consider the bandwidth usage and balance that against the gain in quality. A doubled image width gives roughly four times the file size, so a web page with lots of images can quickly become unreasonably large.

And it gets worse: There is apparently a bug in the iPad browser that makes jpg images (just jpg, not png) that are larger than 2 1024 1024 pixels appear low-res. Until this has been sorted out, you should probably keep your images below this size limit.

Ideally, you’d want the larger images to be used only on the displays that have a large resolution, and send smaller images to all of the rest. There are different JavaScript based solutions for serving different versions of images depending of the screen resolution, including Responsive Images, Adaptive Images and a script that is in use on apple.com. Update: another JS based solution is Foresight.js.

Scaling down background images

Some graphics will be defined as background images, and you may want to make them double in resolution as well. In this case you have to use the CSS3 background-size selector, which is only possible to do in modern browsers. This isn't a big problem, since it's either way a good idea to use media queries to target only high pixel density displays with these larger background images – and devices with this high resolution displays should all understand background-size.

It would look something like this:

Vector graphics on the web

It’s been a dream for a long time to be able to use vector based graphics on web pages. It’s just a perfect fit for a platform that is often bandwidth sensitive to use an imaging method that usually needs only a fraction of the file size to render illustration-like images.

Limited browser support has stood in the way for a long time, as has support for web-ready formats in popular illustration software. Now, most browsers that are not IE have native support for SVG, and Adobe Illustrator does a good job of exporting to this format. For IE support, you can use the svgweb polyfill, or you can use the JavaScript library Raphaël to handle the SVG rendering in all browsers (use this tool to import your SVG images into Raphaël).

Conclusion

The web as we know it today is not going away tomorrow just because that fruit company has released a new tablet. But if appearances are important to you, and you care about the opinions of early iPad adopters, you should perhaps take a look at your site’s most important graphics and make sure it’s retina-ready. Using the techniques described above to boost the appearance of, say, your site logo and main navigation will at least avoid the biggest pain points. If you also go through your site elements and replace background images for things like shadows and rounded corners with CSS equivalents, you’ll soon have come a rather long way toward a decent visual experience on the new iPad.

Originally published at www.sthlmconnection.com.

--

--

Hannes Lilljequist
SthlmConnection

Developer and co-founder of @sthlmconnection. Loves nature and running.