High-resolution displays
Just in case you thought swapping images out based on screen size wasn’t difficult enough, it turns out there is at least one more situation that might require different images: high-resolution displays. The problem really started with the Retina display on the iPhone 4, but it’s been exacerbated by the iPad 3 and the latest versions of the MacBook Pro both supporting a Retina display.
The Retina display sports a whopping 326ppi (pixels per inch) pixel density, compared to 163ppi for the iPhone 3 display. This high density means that images can appear to be incredibly detailed and sharp—if they’re optimized for the display. If they’re not, they will appear grainy and blurry.
Creating images for high-resolution displays means creating larger images, which in turn means larger file sizes. Therein lies the rub. You don’t want to pass these larger images to screens that don’t need them. Currently, there isn’t a great way to do that with content images: it’s the same sort of problem we discussed previously when trying to load images appropriate for different screen widths.
For CSS images, you can use the min-resolution media query for all browsers except those running on WebKit. For WebKit-based browsers, you must use the –webkit-min-device-pixel-ratio media query.
The –webkit-min-device-pixel-ratio media query takes a decimal value representing the pixel ratio. To target the Retina display on the iPhone, iPad, or new MacBook Pro you need a value of at least 2.
The min-resolution media query takes one of two values. The first is the screen resolution in either dots per inch or dots per centimeter. Doing this requires a little math, and some of the early implementations were inaccurate. As a result, I recommend using the new dots per pixel (dppx) unit. Not only does it remove the need for any math (it lines up perfectly with the ratio value accepted by the –webkit-min-device-pixel-ratio media query), but it also avoids the older, incorrect implementations. Support for the dots per pixel unit is still a little sketchy, but since displaying Retina-ready images is a nice enhancement rather than an essential feature, I’m pretty comfortable using it.
1.
header[role="banner"] .inner {2.
background: url('../images/football_bg_lowres.png') bottom right no-repeat;3.
}4.
@media only screen and (-webkit-min-device-pixel-ratio: 2),5.
only screen and (min-resolution: 2dppx) {6.
header[role="banner"] .inner {7.
background: url('../images/football_bg_highres.png') bottom right no-repeat;8.
}9.
}
The above media query targets any device with a pixel ratio of at least 2. Lines 1–3 set the background image for low resolutions. Lines 4 and 5 target devices with a pixel ratio of at least 2. If the pixel ratio is at least 2, then lines 8–10 apply a higher-resolution image for the background.
SVG
One solution for both high-resolution displays and images that scale across screen sizes is Scalable Vector Graphics (SVG). SVG images are vector images whose behavior is defined in XML. This means they can scale well without actually increasing file size. It also means they can be programmatically altered and adjusted.
One great example of how SVG can improve an experience was the solution Bryan Rieger (now at Yiibu) designed for his then employer Future Platforms and their client, the Royal Observatory at Greenwich. The Observatory's Prime Sky project involved a mobile and desktop site featuring detailed constellation diagrams. The maps (and corresponding text labels) were so complex that simply scaling them to suit small screens caused a loss of valuable detail. Using SVG and some smart scaling, Bryan was able to adjust line quality, font size and the overall composition, retaining detail and legibility across all screen sizes (Figure 4.6).
Figure 4.6. Simply resizing the image resulted in a large loss of detail (top right). By using SVG and some smart scaling, adjustments could be made ensuring that the level of detail could be retained, especially keeping text legible (bottom right).
There are two real issues standing in the way of SVG: browser support and lack of tools. As usual, Internet Explorer 8 and under don’t play along. More importantly, neither does the default browser on Android 2.x—the most popular version of that platform. Those browsers that do support SVG images vary in their level, and quality, of support.
The most popular tools for image creation and manipulation, such as Photoshop, are not built with vector formats like SVG in mind. If you want to create SVG images, you need to find another tool to do it in.
As tools and browsers start to catch up, SVG images may become a very common tool in a web developer’s toolbox.