“I skate to where the puck is going to be, not where it has been.”
—Wayne Gretzky
The web is changing.
Before, our biggest worries were the diversity of browsers. How do we get CSS to work across both IE6 and Firefox, let alone Safari.
While cross-browser design is still a challenge, those difficulties have eased with time. Modern versions of Internet Explorer are relatively on par with other browsers.
Most would agree that the biggest challenge facing the web today is multiple devices. Smartphones. Tablets. Even TVs. The diversity of screens we need to design for is only increasing.
Responsive web design, a concept pioneered by Ethan Marcotte, has stepped nobly up to the challenge with a solution that allows us to develop once, and deploy everywhere. Responsive design is challenging, but it is a great toolbox to solve the tricky problems of how to adapt our content, our layout, our typography and our images to a wide variety of screen sizes.
For the last two years, Apple has introduced yet another variable into our design equations: retina images.
The iPhone 4 introduced a screen with a resolution of 326 pixels per inch. The iPhone 4S followed suit last year. This spring, the new iPad offered a 264 pixel per inch display. The retina version of the MacBook Pro released this summer has a 220 pixel per inch display.
Apple calls these “retina” displays because in theory at the distance at which each of these screens would typically be from your retina, you would not be able to discern individual pixels. Whether or not that is actually true, or if that would require a higher pixel per inch density, there is no doubt that these are high resolution displays.
Designing with retina images is a challenge. An image that would take up the entire display of a retina MacBook Pro would be 2,880 pixels by 1,800 pixels. Unsurprisingly, that results in a huge file size.
For a website, if you provide only retina-quality images, that is going to result in slow downloads in low-bandwidth situations. This is particularly egregious for mobile devices that don’t need the same width image as one for a retina-quality laptop screen.
Thankfully, the tools being developed for responsive web design can prove just as useful in handling retina images. The challenge of responsive images is providing appropriate width images depending on the layout available for a particular browser viewport, which potentially depends on the device size.
What proves particularly challenging is that browsers, in trying to speed up page load times, try to prefetch images before anything else in a webpage is loaded. Most responsive image solutions involve using Javascript to detect the viewport size and then switching out the source file for an image appropriate for that viewport size, sometimes storing that size in a cookie to speed up the process the next time.
Prefetching undermines this, and thus often the best option is to have the mobile-sized image available by default, and then switching that out for larger screens. That can still result in more than one hit on the server for a particular image, but it’s better than starting by downloading a really large image for smaller screens that don’t need it. The assumption is that devices with larger screens with typically have higher bandwidth and thus can better absorb multiple hits to the server for the same image.
The most promising solution involves helping the browser to only download one image based on the browser viewport size. This can really only be done if HTML itself is altered. Thus, a new HTML element has been proposed, <picture>, which would allow for multiple <source> elements for various viewport sizes.
While this approach has not yet been standardized, you can try it out today with the Picturefill polyfill, developed by Scott Jehl. In the meantime, the Responsive Images Community, led by Mat Marquis, is working to get the picture element standardized as part of HTML5.
The <picture> element also can provide different image sources for higher-resolution displays. When WHATWG was working on responsive images, they proposed an attribute for the <img> element, srcset, that would allow for setting multiple sources depending on the screen resolution. That has now been integrated into the <picture> proposal, allowing for srcset on each <source> element, thus allowing media queries to determine the right source for each viewport size, and srcset to determine the right resolution for that viewport size.
The pushback I have heard is, why should we really care about high-resolution graphics? After all, only a very small percentage of people have retina MacBook Pros. Why go through all this trouble for just a few Apple fans?
Five years ago, when the iPhone was released, you could have said the same thing about designing for mobile. Most web browsers on mobile phones, prior to the iPhone, were limited in capability. After that, the door opened much wider. Now we have capable browsers not just for iPhones, but for Android, Windows Phones, and yes, even Blackberry.
Already there are plenty of retina screens in the wild, from the iPhone 4 and 4S, as well as the new iPad.
There may not be many retina MacBook Pros out there yet, but Apple didn’t just make those on a whim. Within a year or so, I would expect that all of their displays, from MacBook Airs to iMacs, will have retina displays. And since Apple laptops and iMacs have been increasing their sales every quarter, while PC manufacturers have lost ground every quarter, this does matter.
But it won’t stop there.
Already, there are plenty of other high-resolution screens out there. Here are just a few:
- Nexus 7 (216 ppi)
- HTC Rezound (342 ppi) and One X (312)
- LG Optimus LE (329 ppi)
- Nokia Lumia 800 (252 ppi)
- Samsung Galaxy SIII (306 ppi) and Galaxy Nexus (316 ppi)
There are far more than those listed here, and there will be far more in the future.
Once Apple leads the way on higher-resolution displays for laptops and desktops, PC manufacturers will assuredly follow. For a time, there will be a premium for those displays. Over time, I expect they will become standard.
And if designers want their images to look great on those displays, they will need to provide high-resolution images. And do so in a way that doesn’t provide ginormous images by default, but images of the appropriate size and the appropriate resolution, based on the viewport and the device resolution.
I believe the <picture> element provides the best way forward in doing so.
Other solutions, such as a webkit-only property in CSS, image-set, are counter-productive, or useful only in limited situations. Bruce Lawson does a good job detailing why Webkit’s image-set could cause major accessibility issues, if it was used as the primary way to deal with the need for high-resolution images. This is a prime example of why we need more designers and developers involved with developing solutions.
So if you don’t care about high-resolution images yet, start. Stay informed. Get involved, through the Responsive Images Community at the W3C.
If you work with an open source CMS, find out how they will be implementing solutions for this. I’ve been testing the resp_img module for Drupal 7, which seems promising. That may be brought into core development for Drupal 8. Hopefully Joomla, WordPress and other CMSs will be developing their own solutions.
Whatever you do, don’t sit on the sidelines and heckle, simply because you don’t like Apple, or you think this only will affect a few Apple fans. This is much larger than just Apple. Even if all displays aren’t high resolution in the future, enough of them will be that you won’t be able to ignore it, just as you can no longer ignore mobile design.
Let’s skate to where the puck will be.