What iOS 5.1 and the new iPad mean for web developers

The new iPad is here with iOS 5.1. I’ve done the usual research and, mm… there are no much new details to give you. However, the new iPad retina display remembers us some web stuff we should be aware of while creating iPad web experiences.

Safari on iOS 5 and Safari on iOS 5.1 seems to be exactly the same. There is no new APIs, no new stuff supported, same WebKit version; only we have the version change on the User Agent.

However, iOS 5.1 is the first version supporting high resolution iPads. While there is no real devices yet to test on, there are some ideas we need to remember from the iPhone 4 high definition launch and everything goes in the same direction.

Too many pixels

The iPad has a resolution of 2048 x 1536. It’s far away more pixels than we use to have on the web.

Do we need to change our websites for this new resolution? Well, definitely no.

First, remember that more pixels doesn’t mean more visual space to use. Your website will be rendered as in iPad 1 and iPad 2 with the advantage of sharpen text, CSS3 effects and gradients.

We need to remember that since the appearance of iPhone 4 -and also followed by Android- mobile browsers are exposing a virtual resolution to web developers based on the viewport meta tag and/or an attribute called Pixel Ratio. iPad 1 and iPad 2 have a Pixel Ratio of 1. The new iPad has a Pixel Ratio of 2. This value can be accessed though JavaScript using window.webkitPixelRatio or though CSS media queries using -webkit-device-pixel-ratio. 

If we define a div of 500 pixels-wide, it will be really 500 pixels-wide on iPad and 1,000 pixels-wide on the new iPad, unless an special viewport is defined.

High resolution images

Now we know that we will not have problem with text and CSS3 effects. Images is a very different problem. Basically, the new iPad will resize your image. At the end you will not see much difference from iPad 1 or iPad 2. However, if you provide a high resolution alternative the image will become more clear. You can provide alternative images using the Device Pixel Ratio attribute. In case of CSS3, the code should look like:

@media (-webkit-device-pixel-ratio: 2) {
#someContainer {
background-image: url('images-hi/image.png');
}
}

Icons and launch images

 For WebClip icons -those that iOS uses when the user adds our website to the Home Screen- we can leave the current iPad icon -72×72 pixels- or we can provide a high resolution version -144×144 pixeles- using the same code:

<link rel="apple-touch-icon" sizes="72x72" href="touch-icon-ipad-lo.png" />
<link rel="apple-touch-icon" sizes="144x144" href="touch-icon-ipad-hi.png" />

If you are creating a chromeless app then you may know about apple-touch-startup-image link element. There is no official way to define different sizes on this element. However, a trick using media queries is working for delivering landscape and portrait versions right now so it’s possible to have this working for high resolution images too.

Performance

Wait before looking for high resolution versions of your images. If we think about it, we need an image with four times pixels. That’s a huge difference and the image size will be much higher. What does this mean? Your page will be much slower. Ok, there is a 4G version of the new iPad but that doesn’t mean that the difference will be covered.

Think twice about the value added when delivering high resolution images.

Creating effects and gradients using CSS3 will be much faster. However, large backgrounds tends to use lot of memory. Fortunately, the new iPad comes with more memory and CPU power so hopefully this won’t be a problem.

Maybe it’s time to start looking at scalable solution, such as SVG that will take advantage of the high resolution without harming network performance.

In terms of HTML5 games, we need to wait until having the real device but usually if you want to increase your frame rate sometimes it’s better to provide a smaller viewport, so the game will use less memory -like a iPad 2 emulator- and using hardware accelerated CSS3 transforms we can scale it if we need to. It’s just a thought and a trick that is being used in some Android HTML5 games to gain some frames per seconds.

 

 

Share

Tags:

Loading Facebook Comments ...
  1. #1 written by Brad Frost March 9th, 2012 at 16:07

    Great post, Max! I wrote about the resolution issue as well: http://bradfrostweb.com/blog/notes/ipad3s-retina-display-web/ and what to do about it: http://bradfrostweb.com/blog/mobile/hi-res-optimization/

    I really like how you say “Think twice about the value added when delivering high resolution images.” It’s a decision that requires a lot of consideration.

    RE Q
  2. #2 written by Kristofer Layon March 9th, 2012 at 16:24

    Great analysis of opportunities both good and bad. Apple puts us in an interesting position, as it is somewhat inevitable that display quality would improve for the web, just as it has for television with HD over the past few years.

    The trouble with the web, of course, is that the standards for web devices and web “broadcasting” are not synced up in a tidy process as they are for television — it’s just not as regulated as television is. So on the web, our process is quite a bit more messy and takes a lot longer. Yay for freedom and less regulation, but boo that there’s also a significant downside…

    As designers, we have to be aware and respectful of the position in which we’re being put by Apple. Until network capabilities and costs improve for the “broadcasting” to catch up with hardware capabilities, I agree that we need to be very cautious about delivering larger images. Let’s not jump the shark. =)

    RE Q
  3. #3 written by Joe Lambert March 11th, 2012 at 09:06

    Great writeup, I’ve written a couple of mixins for Compass/SASS that make it easier to manage retina assets (@x2) in the web dev workflow. Might be of interest:

    http://blog.joelambert.co.uk/2012/03/09/compass-sass-mixins-for-simple-retina-images-on-websites/

    RE Q

SetPageWidth