The US presidential race is heading into full swing, which means we’ll soon see the candidates intensely debate the country’s hot-button issues. While the candidates are busy battling it out, the Web design world is entrenched in its own debate about how to address the mobile Web: creating separate mobile websites versus creating responsive websites.

It just so happens that the two US presidential candidates have chosen different mobile strategies for their official websites. In the red corner is Republican candidate Mitt Romney’s dedicated mobile website, and in the blue corner is incumbent Barack Obama’s responsive website.

We’re going to see how well their mobile Web experiences stack up. But before we do, we need to ask a few questions.

Why Bother With Mobile?

Why are the candidates attempting to create mobile-optimized Web experiences? Well, the US population is sitting at around 311 million. Of those 311 million people, about half of US adults own a smartphone. On top of that, for a whopping 28% of Americans, a mobile device is their primary way of accessing the Web. So, for a candidate looking to reach potential voters, mobile provides a tremendous opportunity to connect with their constituents.

What’s more is that people are arriving to the mobile Web through more diverse channels than ever before. In addition to direct and referral traffic, candidates are using social networks, email campaigns, SMS campaigns, search and more. Because these activities are increasingly happening on mobile, creating Web experiences optimized for mobile makes even more sense for the candidates.

These are just a few channels that drive people to the Web on mobile devices.

The candidates see mobile as a big opportunity to turn visitors into voters. We can see the candidates’ incentive, but now we must ask another important “Why” question.

Why Would Anyone Visit A Candidate’s Website?

Who is visiting these candidates’ websites? What are they looking for? Why might they want on a mobile device?

Visitors are generally either looking for information on the candidates or looking to take action.

The Information-Oriented Visitor

The information-oriented user might be looking for basic information about the candidate, such as his biography, background or stance on issues. They might also be interested in regularly updated information such as news, locale-specific blog posts and information like myth busting (where the candidate tries to dispel nasty rumors circulating in the media). The official websites give the candidates a chance to deliver information straight from the horse’s mouth, free from news media bias and inaccuracies that arise from crowd-sourced information.

The Action-Oriented Visitor

The action-oriented user is looking to support the candidate in some way, shape or form. Both websites prominently feature calls to action asking visitors to donate money to the campaign and to sign up for their email newsletter. Action-oriented users might also want to connect with the candidates on social media channels, volunteer their time at an event, make calls on the candidate’s behalf or shop for merchandise.

The candidates have accounted for these use cases in their Web experiences. Let’s look at how they execute on mobile.

Criteria For Judging: Layon’s Theory of Mobile Motivation

The effectiveness of Romney and Obama’s positions on the economy, foreign policy, social issues and other important subjects depends on certain criteria. Likewise, we need to establish a set of criteria to determine the effectiveness of the candidates’ mobile Web experiences.

Mobile Web designer Kristofer Layon has a clever way of looking at the hierarchy of mobile needs. His “theory of mobile motivation” is based on Maslow’s hierarchy of needs, a psychological theory that identifies the various levels of human needs.

Maslow’s hierarchy of needs.

Kristofer Layon has applied that theory to the needs of mobile Web users, where primary access and navigation are the most essential aspects of an experience, and at the top of the pyramid are HTML5 enhancements (such as offline storage and a boatload of other features).

Layon’s hierarchy of mobile needs.

Let’s apply a simplified version of Kristofer’s hierarchy to evaluate how well each candidate’s website holds up.

My simplified version of Layon’s hierarchy of mobile needs.

Access

First and foremost, users need to be able to access an experience. The most beautiful design in the world will accomplish nothing if people can’t view it. Historically, the mobile Web has been viewed as the Web Lite™, whose users get served only a subset of content and functionality. However, a whopping 28% of US residents use a mobile device as their primary way to access the Web. With more people relying on their mobile devices to access the Web, achieving content parity and giving users access to a full experience regardless of their device or configuration are more important than ever. Let’s see how the presidential candidates’ mobile Web experiences hold up.

Barack Obama

Barack Obama’s “mobile” website has no “full site” link because it shares the same code base as the “desktop” website. Content on a responsive website lives under one roof, which gives the website a better chance of achieving content parity. And while responsive designers can (and do) hide content from small-screen users, responsive design affords less opportunity to fork the content and create disparate experiences, which would deprive certain users of valuable information and features.

Mitt Romney

Mitt Romney’s website uses device detection to route mobile users to a separate dedicated website. Creating this separate experience allows the designers to tailor the mobile Web experience, but a separate design and subdomain also opens the door to some serious problems.

The main problem with Mitt Romney’s mobile website is that only a fraction of the full website’s features are included.

Only some of the features from the full website have made it onto the mobile-specific website.

It’s a myth that mobile users don’t want access to all of the information and functionality available to desktop users. The absence of key content on Romney’s mobile website leaves a lot of serious questions unanswered for potential supporters, such as “Who is this guy, anyway?,” “Where does he stand on issues?,” “What’s his plan for the economy?,” “What can he do for my state?” and “Where can I shop?”

Another common problem with separate mobile websites is URL management. Because desktop and mobile content live at separate URLs, device detection is required to route users to the appropriate site. Unfortunately, many websites don’t go deep enough in their URL redirection, so desktop users will get sent to mobile content and vice versa. This becomes apparent when mobile content gets shared by mobile users on social networks and then gets accessed by desktop users:

Issues arise when a mobile URL is accessed from a desktop.

As we can see, having Web content all under the same roof and URL definitely makes it easier to give visitors access to the content they’re looking for, regardless of the device they happen to be using.

Interact

Basic access to a website is essential, but what happens once the visitor is on the website? They need to be able to interact with the content and get around the website. Let’s start with one of the most common and important interactions: navigation.

Navigation

Navigation, especially on mobile, should be like a good friend: there when you need it, but considerate enough to give you your space. When navigation takes up a ton of real estate, it gets in the way and becomes that annoying friend who won’t leave you alone. When it’s inaccessible, hidden or just hard to reach, it becomes that friend who’s conveniently absent when you’re looking for help to move to your new apartment.

Barack Obama

Obama’s website serves navigation at the top for large screens and then transforms it into a left fly-out menu for screens narrower than 1024 pixels.

Obama’s website has Facebook-esque left fly-out navigation for small screen resolutions. Among popular responsive techniques, this one is relatively complex and opens the door to problems. As Stephanie Rieger points out in her post “A Plea for Progressive Enhancement,” Obama’s navigation fails on a whole load of mobile devices: “And the menu failed. Never even opened. Suddenly, the site was without navigation… at all.”

These situations, regardless of approach, can be avoided using proper progressive-enhancement techniques, but it’s a good example of the challenges that arise when creating adaptive experiences.

Mitt Romney

Romney’s mobile website has a dashboard home page and “Back” and “Home” links for inner pages. The full website has top navigation.

Romney’s relatively simple mobile navigation contrasts starkly with Obama’s navigation. It sits as a dashboard on the home page, and all inner pages simply include a “Back” button and a logo that links back to the home page.

This navigation technique certainly solves the problem of limited real estate and avoids complexity, but it creates other issues. Requiring a full page refresh just to jump to another section of the website isn’t very efficient. A logo as a button doesn’t exactly scream “Click me for navigation!” And the “Back” button does nothing if the visitor arrives at the website on a page other than the home page. It’s also worth noting that mobile browsers already have their own back buttons, so duplicating that functionality in the header could be regarded as wasted space.

Scrolling

Scrolling is an interesting interaction on mobile devices. The “fold” as a set pixel value is a myth, but users still need to be able to access the core content as quickly as possible.

Mitt Romney

Romney’s mobile website has an acceptable page length. Not much chrome or clutter before you get to the core content, and for the most part the user doesn’t have to scroll much to find what they need.

Barack Obama

Obama’s pages contain a massive amount of content, often introducing entirely new sections far down in the flow. The result is extremely long pages that have serious problems.

Scrolling through disparate content types is not a good experience. How do users figure out that other content exists? Finding what they’re looking for becomes a scavenger hunt. While they might be all right with sifting through one or two content types (for example, a blog’s main article and subsequent sidebar), a lot of disparate types makes the content unfindable and the page impractical.

While content parity is essential for mobile users, that doesn’t mean websites have to be one size fits all. Techniques like lazy loading and conditional loading enable Web creators to provide access to full content without having to stuff it all on the page at the same time. And while those techniques can be extremely effective, there’s no substitute for subtracting supplementary content everywhere to focus on core content.

In addition to the annoyance caused by having to scroll through so much content, these massively long pages have another downside: terrible performance.

Perform

Performance has gotten the short end of the stick. Web creators have assumed too much about the user’s context (“Of course, the user has a fast connection!” “Of course, their machine is powerful!”). As a result of these convenient assumptions, the average page now weighs a whopping 1 MB.

One MB might not seem like a big deal until we look at the mobile user’s expectations. 71% of mobile users expect mobile websites to load as fast, if not faster, than desktop websites, and 74% of mobile visitors will abandon a website if it takes more than 5 seconds to load. In other words, you have 5 seconds to get someone’s attention. Make it count.

To evaluate how well the candidates’ websites perform, we’ll use the excellent Blaze.io mobile performance test to capture performance results on real devices.

Mitt Romney

A typical page on Romney’s mobile website is about 687 KB and, as a result, takes about 8.75 seconds to load. While that’s over the 5-second mark, the pages still weigh less than the average size.

Barack Obama

A typical page on Obama’s responsive website is a massive 4.2 MB, resulting in a 25-second loading time.

Despite the fact that only the most patient of visitors would wait 25 seconds for a page to load, such a large payload creates real accessibility problems. Some devices (such as my cousin’s company-issued BlackBerry) won’t even render the page because it’s too large.

While some of this is RIM’s or my cousin’s employer’s doing, it’s a legitimate constraint that we need to be mindful of.

Unfortunately, poor performance is prevalent among the current crop of responsive designs in the wild. Guy Podjarny, chief product architect at Akamai and CTO of Blaze.io, discovered that only 3% of small-screen versions of responsive websites are significantly lighter than their large-screen counterparts. This is all the more reason to focus on performance as a key component of adaptive Web design.

Enhance

We’ve talked about content parity and the importance of providing access to information and functionality regardless of device or configuration. But that doesn’t mean we have to settle on serving a one-size-fits-all experience. Many mobile devices and browsers can do things that desktops cannot. Making the most of these wonderful features will take the mobile experience to the next level.

Mobile Communication

Obama’s designers have implemented one huge enhancement: the ability to make calls on the candidate’s behalf directly from a phone. We tend to forget that mobile phones are, at root, voice-based communication devices and that mobile browsers can initiate a call when the user clicks a tel link. By exploiting this enhancement, Obama is able to mobilize his mobile users into action, which could have a big impact on the campaign.

Obama’s call functionality enables users to make calls on the candidate’s behalf, right from their phones.

Besides enabling phone calls to be initiated from the browser, there are many other opportunities for mobile enhancement. Here are just a few ways that both websites could enhance the experience and make the most of the mobile Web.

Simple Form Enhancements

The great thing about form enhancements is that they require barely any effort. One enhancement for many mobile browsers is to specify an HTML5 input type to pull up the appropriate virtual keyboard for the user. While this enhancement isn’t particularly mind-blowing, anything that allows the user to complete their task more quickly certainly helps and could lead to more conversions.

Setting these forms to input type=number would pull up the appropriate virtual keyboard, thus saving the user an extra step.

Geolocation

Detecting location is an extremely powerful way to provide users with contextually relevant information. Imagine dynamically displaying blog posts, news and upcoming events relevant to the user’s location. Obama’s website smartly allows users to choose their state; perhaps they could take it further and add geolocation as a way to identify it. Geolocation can also save steps when filling out forms, and it creates opportunities for innovative new features.

Touch Events

The beauty of touchscreens is that they give users a way to interact directly with content and can add a layer of fun to the experience. These websites could leverage touch events to allow users to swipe through photos in a gallery or to thumb through a quick overview of the candidates’ stances on important issues.

Many More

This is just a small sampling of enhancements. Support for a ton of features can be detected, and a ton of use cases emerge from the plethora of devices that access the Web. Ask questions. “Can I offer features that are useful to users on the go?” “How might I use offline storage to improve the experience?” “How can I take advantage of touch events?” Lay a solid foundation, and look for opportunities to enhance.

So, Who Wins?

If there’s one lesson to learn from analyzing these websites and techniques, it’s that this stuff is genuinely hard. A lot goes into making a great mobile Web experience, and I’m personally thrilled that the candidates have taken the important first steps toward making their websites mobile-friendly. Viewing the mobile web as a wonderful journey and not as a destination is absolutely essential. As we step into the deep end of multi-device Web design, we must strive to continually improve our websites and services in order to better serve our users — wherever they may be.

While the design of a candidate’s website might not determine the outcome of the presidential election, it will certainly influence how the world perceives the candidate. And for a Web-savvy voter like myself, a website’s design might just sway my vote. I know who I’m voting for in November!

(al)

• By David Bushell
• January 16th, 2012
• CSS

In this article, we’ll look at Scalable Vector Graphics (SVG), one of the most underused technologies in website development today.

Before diving into an example, let’s consider the state of the Web at present and where it is going. Website design has found new vigor in recent years, with the evolving technique of responsive design. And for good reason: essentially, responsive website design moves us away from the fixed-width pages we’ve grown accustomed to, replacing them with shape-shifting layouts and intelligent reflowing of content. Add to that a thoughtful content strategy and mobile-first approach, and we’re starting to offer an experience that adapts across devices and browsers to suit the user’s context.

When we look at the breadth of Web-enabled devices, responsive design is sure to provide a better user experience. Scrolling horizontally, panning and zooming the viewport have their place in user interface design, but forcing the user to do these things just to navigate a website quickly becomes tedious. Fitting the website to the viewport is about more than just layout: it’s also about resolution. In this article, I’ll demonstrate why SVG is a perfect addition to future-friendly Web development.

Introducing SVG

SVG offers a truly resolution-independent technique for presenting graphics on the Web. SVG is a vector graphics format that uses XML to define basic properties such as paths, shapes, fonts and colors, and more advanced features such as gradients, filters, scripting and animation. Create the file once and use it anywhere, at any scale and resolution.

Consider the use cases: UI and navigation icons, vector-style illustrations, patterns and repeating backgrounds. For all of these, a scalable graphic is the perfect solution from a visual standpoint, and yet fixed-resolution images are still the norm. In the example below, we’ll show you how to expand on a common development technique to take advantage of SVG.

A Case Study: CSS Sprites

We all know about the CSS sprites technique. (If you don’t, then have a quick read through Sven Lennartz’ article. And Louis Lazaris points out its pros and cons.) In the example below, we’ll show how seamlessly SVG replaces normal raster images. If this technique is not for you, you can certainly imagine a whole array of similar situations in which to use SVG.

Vector icons play a big role in user interface design. Pictures express concepts with vivid clarity, whereas their textual counterparts might carry ambiguity. In UI design, where space is scarce, a simple illustrated icon could be greatly welcome.

I’ve mocked up the following example:

I’ll be first to admit that this row of icons won’t win any design awards, but it will suffice for the sake of this article! Let’s look at the HTML:

<div class="actions">
 <a class="a-share" href="#">Share</a>
 <a class="a-print" href="#">Print</a>
 <a class="a-tag" href="#">Tag</a>
 <a class="a-delete" href="#">Delete</a>
</div>

I’ve kept the HTML to a minimum for clarity, but in practice you’d probably want to mark it up with an unordered list. And you’ll almost certainly want to replace those hashes with real URLs (even if JavaScript provides the functionality, having a fallback is nice). Let’s look at the CSS:

.actions {
 display: block;
 overflow: auto;
}
.actions a {
 background-image: url('sprite.png');
 background-repeat: no-repeat;
 background-color: #ccc;
 border-radius: 5px;
 display: block;
 float: left;
 color: #444;
 font-size: 16px;
 font-weight: bold;
 line-height: 20px;
 text-decoration: none;
 text-shadow: 0 -1px 2px #fff;
 padding: 10px 20px 10px 40px;
 margin-right: 5px;
}
.a-share { background-position: 10px 0; }
.a-print { background-position: 10px -40px; }
.a-tag { background-position: 10px -80px; }
.a-delete { background-position: 10px -120px; }

Note the fixed-pixel sizing and the PNG background, which we can see below framed in full Photoshop production glory:

This implementation of a CSS sprite is basic, and at today’s standard, it’s not good enough! How can we enhance this? First, let’s consider the following issues:

1. We’ve rasterized the image at a very early stage. Even at full size, icons in which points sit between pixels, such as the one for “Print,” have blurred.
2. If we zoom in, the image will blur or pixellate even more; there is no additional data to re-render the image at larger sizes.
3. Everything has a fixed size, which is neither good for responsive design nor good for accessibility, because the browser’s default font size is ignored.

As you’ve probably guessed by now, we’ll show you how SVG solves these problems. But first, let’s reiterate each point thoroughly to understand the issues at large.

1. Rasterization

Devices such as modern smartphones have a very high pixel density; some already surpass the 300 pixels-per-inch (PPI) mark that is assumed to be the limit of the human eye’s ability to distinguish fine details. A pixel has no real-world equivalent in size until it sits on a screen of fixed dimension (say, 3.5 inches diagonally) and fixed resolution (say, 640 × 960 pixels). At this scale, text with a font size of 16 pixels would be incredibly small to the eye. For this reason, devices simply cannot translate 1 CSS pixel unit to 1 device pixel; instead, they double up. Thus, a 16-pixel font size actually takes over 32 pixels when rendered.

The same applies to images; but they are already rasterized, so doubling up the pixels has no benefit. In our example, each icon has been rasterized at around 25 × 25 pixels (the whole sprite being 30 × 160), so they cannot take advantage of the double pixel ratio. One solution is to use CSS media queries to detect the pixel ratio. This is already implemented in Webkit- and Gecko-based browsers.

To improve our example, we can add the following CSS declaration:

@media only screen and (-webkit-min-device-pixel-ratio: 2) {
 .actions a {
 background-image: url('sprite@2x.png');
 background-size: 30px 160px;
 }
}

The alternate background image supplied in the code above has been saved at 60 × 320 pixels (i.e. double the original dimensions). The background-size property tells CSS to treat it smaller. Significantly, now the device has the additional data to render a better image (if capable).

This solution isn’t bad, but it doesn’t solve the problems we’ll run into in points 2 and 3 below. It also requires that we maintain multiple files of increasing size: a potential burden on bandwidth and a real hassle. For non-vector images, such as photography in JPG format, we can’t do much more than that.

2. Zooming

At their default size, our rasterized icons look acceptable, at least on low-pixel-density screens. However, should the user zoom in on the Web page, these little UI delights will degrade very quickly.

Zooming is a common action when users find a website too small for comfortable viewing. Or, to put it another way, websites that are designed too small are very common. There is really no “perfect” size, because almost everyone has at least some level of visual impairment, since our eyes inevitably deteriorate with age. Secondly, with the rapid increase in touchscreen devices, pinch-to-zoom has become the standard way to enlarge fixed-sized content designed for larger screens (i.e. much of the Web today).

We should develop websites in a way that minimizes the need for user input — that’s where responsive design comes in (see point 3 below) — but zooming is here to stay. There’s simply no way to provide pre-rasterized images for every level of zoom (in theory, an infinite scale). Scalable graphics are the solution, and we’ll show you how to enhance our example. But first, a related word on fixed sizing.

3. Fixed Sizes

Presenting page elements at fixed sizes forces many users to zoom, but it also disables a very useful browser feature. Users can set their preferred font size (the default in browsers is 16 pixels). By sizing everything in pixels, we override this preference. Sizing elements based on this default is much better, so that, if the text is bigger, everything adjusts to match. This essentially mimics the zooming effect but happens without the user having to manually do it on every visit. Ethan Marcotte has written a great article that explains relative font sizes.

Let’s re-implement our sprite example with a solution to these three issues.

A Scalable Implementation

Here is the HTML again. We don’t need to change anything here.

<div class="actions">
 <a class="a-share" href="#">Share</a>
 <a class="a-print" href="#">Print</a>
 <a class="a-tag" href="#">Tag</a>
 <a class="a-delete" href="#">Delete</a>
</div>

The updated CSS is where the magic happens:

body { font-size: 100%; }
.actions {
 display: block;
 overflow: auto;
}
.actions a {
 font-size: 1em;
 line-height: 1.25em;
 padding: 0.625em 1.25em 0.625em 2.5em;
 margin-right: 0.3125em;
 border-radius: 0.3125em;
 background-image: url('sprite.svg');
 -webkit-background-size: 1.875em 10em;
 -o-background-size: 1.875em 10em;
 -moz-background-size: 1.875em 10em;
 background-size: 1.875em 10em;
 /* styles carried over from the original implementation */
 background-repeat: no-repeat;
 background-color: #ccc;
 color: #444;
 display: block;
 float: left;
 text-decoration: none;
 text-shadow: 0 -1px 2px #fff;
}
.actions-em .a-share { background-position: 0.625em 0; }
.actions-em .a-print { background-position: 0.625em -2.5em; }
.actions-em .a-tag { background-position: 0.625em -5.0em; }
.actions-em .a-delete { background-position: 0.625em -7.5em; }

In this version, we’ve made the following changes:

• The background-image is now an SVG file.
• All sizes are based on the default of 16 pixels, or 1 em. If the user’s default is larger or smaller, then everything will scale relatively. (If you multiple each em size by 16, you’ll get the number of pixels used in our initial fixed-size example.)
• The background-size is very important. By setting this in em units, we’re telling the browser to scale the sprite relative to everything else. You’ll notice that 1.875 × 10 em multiplied by 16 becomes 30 × 160 — the base size at which we produced the sprite in pixels.
• The background-position of each sprited icon is also based on relative units.

Now that we’re using SVG and relative sizes, we have solved the three big issues highlighted above. A scalable graphic can be rasterized on demand to perfectly suit any device resolution and any zoom level. By using relative sizes, we can continue implementing a responsive design, minimizing as much as possible the need for the user to zoom. We’re also respecting the browser’s default font size, and enabling our design to adapt accordingly.

I actually produced the SVG sprite first and the PNG version from that. (I imported the SVG in Photoshop before exporting it as a PNG — Illustrator’s PNG export had very poor rasterization.) Below is the header in my SVG file. Notice the same 30 × 160 initial size.

<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
 width="30px" height="160px" viewBox="0 0 30 160" enable-background="new 0 0 30 160" xml:space="preserve">

You can see that the attributes for width and height are set in pixels (width="30px" height="160px") in the opening svg tag (as generated by Adobe Illustrator). This actually causes it to render early in Firefox, before the graphic has scaled to match the em sizes in background-size. Webkit-based browsers seem to scale the SVG perfectly, regardless. I’ve found that editing the SVG file to use em units in these two attributes fixes any rendering issues in Firefox.

<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
 width="30em" height="160em" viewBox="0 0 30 160" enable-background="new 0 0 30 160" xml:space="preserve">

I don’t know which browser actually implements this scaling correctly, but let it be noted that extra care is needed to ensure cross-browser perfection. Mozilla MDN has an excellent in-depth article, “Scaling of SVG Backgrounds,” which explores more practical examples. For more ideas, see Alex Walker’s article “A Farewell to CSS3 Gradients.”

Here’s a super-close screenshot showing the SVG sprite:

The sprite scales beautifully. (Sadly, the same can’t be said for my tacky text-shadow effect.)

It’s best to experience the joys of scalable graphics and relative sizing firsthand. I’ve uploaded a side-by-side live demo demonstrating a combination of all the techniques mentioned above.

Browser Support

At the start of this article, I said that SVG was underused. I believe that has generally been the case due to poor browser support. But things are different now! Browser support for SVG has blossomed over the last year to the point where implementing it is a viable use of development time.

According to the website When Can I Use?, support for SVG across multiple implementations is as follows (I’ve combined support for both CSS’ background-image and HTML’s img source — the most useful attributes):

• Internet Explorer 9+
• Firefox 4+
• Chrome 4+
• Safari 4+
• Opera 9.5+

Mobile browser support is also pretty much across the board. If a workable fallback exists for older browsers, then SVG is a very viable solution.

For some of the new additions to Web standards, we can implement them safe in the knowledge that old browsers will simply ignore them and that they aren’t even required. We call this “progressive enhancement”: better browsers get a progressively better experience. SVG is slightly different, because for most practical purposes, it simply replaces other images in CSS backgrounds and HTML elements. The image format — be it SVG, PNG, JPG or GIF — is either supported or it isn’t. We can’t simply follow the practice of progressive enhancement here, because an image failing to render is not an acceptable experience.

Browser Sniffing or Feature Detection?

We could make an educated guess and say that we need to worry only about users of Internet Explorer 6 to 8. In this case, the conditional comments technique for IE-only styles enable us to re-apply a second CSS background-image of a supported format such as PNG, instead of the default SVG background.

Browsing sniffing is always a dangerous game. While Internet Explorer tends to be the main offender, we can never assume it is the only one.

The safer and highly recommended option is to detect SVG support and use it only if it’s found. I suggest using Modernizr if you need to detect multiple features. Modernizr applies a class of svg to your root html element if detected (to which you can apply SVG as a background-image). If you’re using SVG as the source of an image element in HTML, then implementation is a little harder. You’ll have to write more JavaScript to find and replace all sources once support has been established.

The problem with these methods is that the browser will download the fallback image before SVG is detected — the only exception being the conditional comments technique for IE. Users will also likely see a flash of re-styled content when the source image changes. This shouldn’t be the case for long; but at least for now, these problems may be enough to hold you off on SVG usage.

File Size

In our sprite example, the raw SVG file was 2445 bytes. The PNG version was only 1064 bytes, and the double-sized PNG for double-pixel ratio devices was 1932 bytes. On first appearance, the vector file loses on all accounts, but for larger images, the raster version more quickly escalates in size.

SVG files are also human-readable due to being in XML format. They generally comprise a very limited range of characters, which means they can be heavily Gzip-compressed when sent over HTTP. This means that the actual download size is many times smaller than the raw file — easily beyond 30%, probably a lot more. Raster image formats such as PNG and JPG are already compressed to their fullest extent.

Performance

Rendering performance is a concern with SVG, especially on mobile devices, whose hardware is limited. Raster images can be rendered pixel for pixel after decompression and de-encoding. Vector graphics need to be rasterized at a specific resolution every time they’re viewed.

SVG has consistently proved slower than Canvas as a platform for animating vector graphics; but our concern here is basic rendering, not manipulation a thousand times per second, and if that is possible, then simple rendering shouldn’t be a concern. The more intensive SVG features are things like clipping masks and filter effects. These are unnecessary for many practical purposes (like our sprite example), but, if required, the best way to check performance is by testing. A lot of Web development is supported in theory, but in practice results are far from perfect.

Alternative Methods

Hopefully you agree that SVG is extremely useful but not always the ideal solution to resolution independence. Ultimately, the trick is to avoid raster images while maintaining the scalability of visual styles. Below are a few more ideas to think about.

CSS3

You’ve probably already started combining CSS3 properties such as linear-gradient, text-shadow and box-shadow to create more complex styles. Web developer Lea Verou curates a CSS3 pattern gallery that shows off the impressive potential of gradients alone.

In his article “Mobile Web in High Resolution,” Brad Birdsall introduces a technique to maintain pixel perfection for high-resolution displays using the pixel-ratio property.

Then there are pure CSS “icons,” which Faruk Ateş rightly points out as being absolute “madness” — certainly so if you’re using CSS to create a logo! But you could argue the benefits of a small handful of very specific techniques, such as CSS triangles, as demoed by Chris Coyier.

Web Fonts

Dingbat Web fonts and look-a-like Unicode glyphs are two interesting alternatives for vector icons, both with accessibility and semantic challenges. Jon Hicks has a write-up of perhaps the best practice for this. SVG seems a more appropriate technique for icons, but both have an immediate visual impact at high resolutions — and we’ll be paying increasing attention to that in coming years.

Looking Forward

As you can see, SVG usage is very much a possibility, and browser support and performance will only improve in future. What’s important to note from this article is that we really should be building websites that are as resolution-independent as possible.

Consider the “one Web” philosophy and the vast range of devices we use to access it — there is no single user experience. The more we can do to stay device-agnostic, the better. Responsive website design addresses many of these needs and certainly provides many benefits. Using vector graphics may not be as apparent, but its little improvements really do make a difference.

With today’s level of support, many users can experience the beauty of crisp scalable graphics… or perhaps that’s the wrong way to think about it. Most users won’t say “Wow! Kudos on the vectors.” To our dismay, they probably wouldn’t even consider them (and certainly wouldn’t recognize the effort required to craft them). And that’s a good thing; each time we improve the user’s experience, we don’t necessarily need to make a song and dance about it. Letting things continue to grind away under-appreciated is OK. It’s the lack of such things that gets recognized and sniffed at. Raise the user’s expectations in visual aesthetics, and they’ll start to notice the websites that do look shoddy. If you don’t do it, others will.

(al)

• By Reda Lemeden
• August 20th, 2012
• CSS, HTML

With the recent announcement and release of the Retina Macbook Pro, Apple has brought double-density screens to all of the product categories in its current lineup, significantly paving the way for the next wave of display standards. While the fourth-generation iPhone gave us a taste of the “non-Retina” Web in 2010, we had to wait for the third-generation iPad to fully realize how fuzzy and outdated our Web graphics and content images are.

In the confines of Apple’s walled garden, popular native apps get updated with Retina graphics in a timely fashion, with the help of a solid SDK and a well-documented transition process. By contrast, the Web is a gargantuan mass whose very open nature makes the transition to higher-density displays slow and painful. In the absence of industry-wide standards to streamline the process, each Web designer and developer is left to ensure that their users are getting the best experience, regardless of the display they are using.

Before diving into the nitty gritty, let’s briefly cover some basic notions that are key to understanding the challenges and constraints of designing for multiple display densities.

Device Pixels

A device pixel (or physical pixel) is the tiniest physical unit in a display. Each and every pixel sets its own color and brightness as instructed by the operating system, while the imperceptible distance between these tiny dots takes care of tricking the eye into perceiving the full image.

Screen density refers to the number of device pixels on a physical surface. It is often measured in pixels per inch (PPI). Apple has coined the marketing term “Retina” for its double-density displays, claiming that the human eye can no longer distinguish individual pixels on the screen from a “natural” viewing distance.

CSS Pixels

A CSS pixel is an abstract unit used by browsers to precisely and consistently draw content on Web pages. Generically, CSS pixels are referred to as device-independent pixels (DIPs). On standard-density displays, 1 CSS pixel corresponds to 1 device pixel.

<div height="200" width="300"></div>

This would use 200 × 300 device pixels to be drawn on screen. On a Retina display, the same div would use 400 × 600 device pixels in order to keep the same physical size, resulting in four times more pixels, as shown in the figure below.

On a Retina display, four times as many device pixels are on the same physical surface.

The ratio between device pixels and CSS pixels can be obtained using the following media query and its vendor-specific equivalents:

 device-pixel-ratio,
 -o-device-pixel-ratio,
 -moz-device-pixel-ratio,
-Webkit-device-pixel-ratio {
…
}

Or you can use their future-proof siblings:

 device-pixel-ratio,
 -o-min-device-pixel-ratio,
 min--moz-device-pixel-ratio,
-Webkit-min-device-pixel-ratio {
…
}

In Javascript, window.devicePixelRatio can be used to obtain the same ratio, although browser support is still relatively limited. Both of these techniques will be discussed in depth later in this article.

Bitmap Pixels

A bitmap pixel is the smallest unit of data in a raster image (PNG, JPG, GIF, etc). Each pixel contains information on how it is to be displayed, including its position in the image’s coordinate system and its color. Some image formats can store additional per-pixel data, such as opacity (which is the alpha channel).

Beside its raster resolution, an image on the Web has an abstract size, defined in CSS pixels. The browser squeezes or stretches the image based on its CSS height or width during the rendering process.

When a raster image is displayed at full size on a standard-density display, 1 bitmap pixel corresponds to 1 device pixel, resulting in a full-fidelity representation. Because a bitmap pixel can’t be further divided, it gets multiplied by four on Retina displays to preserve the same physical size of the image, losing detail along the way.

Each bitmap pixel gets multiplied by four to fill the same physical surface on a Retina display.

The Tool Chest

Even though we are still in the early stages of this major shift, several approaches to optimizing Web graphics for Retina displays have sprung up, and more are popping up as we speak. Each method makes some degree of compromise between performance, ease of implementation and cross-browser support. As such, choosing a tool should be done case by case, taking into account both quantitative and qualitative factors.

HTML And CSS Sizing

The most straightforward way to serve Retina-ready Web graphics is to halve the size of your raster assets using CSS or HTML, either manually or programatically. For instance, to serve a 200 × 300-pixel image (remember, those are CSS pixels), you would upload an image with a bitmap resolution of 400 × 600 pixels to your server, then shrink it by exactly 50% using CSS properties or HTML attributes. On a standard-resolution display, the result would be an image rendered with four times fewer pixels than its full bitmap size — a process commonly referred to as downsampling.

A CSS-sized image gets its dimensions halved during the rendering process.

Because the same image would use four times as many physical pixels on a Retina screen, every physical pixel ends up matching exactly 1 bitmap pixel, allowing the image to render at full fidelity once again.

CSS-sized images regain their full-detail glory on Retina displays.

There are several ways to achieve this:

Using HTML

The easiest way to apply CSS sizing would be by using the width and height attributes of the img tag:

<img src="example@2x.png" width="200" height="300" />

Please note that, even though specifying height is optional, it allows the browser to reserve the space required for the image before loading it. This prevents the page layout from changing as the image loads.

What to use it for? Single-page websites with few content images.

Using Javascript

The same result can also be obtained using Javascript by targeting all Retina-ready content images in the document and halving their sizes. With the help of jQuery, this would look like this:

$(window).load(function() {
 var images = $('img');
 images.each(function(i) {
 $(this).width($(this).width() / 2);
 });
});

What to use it for? Websites with few content images.

Using CSS (SCSS)

If you want to keep all of the presentation code in your CSS files, then the most common technique involves setting the image as the background of another HTML element, usually a div, then specifying its background-size property. You could either set explicit width and height values for the background image or use the contain value if the dimensions of the HTML element are already specified. It is worth noting that the background-size property is not supported in IE 7 or 8.

.image {
 background-image: url(example@2x.png);
 background-size: 200px 300px;
 /* Alternatively background-size: contain; */
 height: 300px;
 width: 200px;
}

You could also target a :before or :after pseudo-element instead:

.image-container:before {
 background-image: url(example@2x.png);
 background-size: 200px 300px;
 content:'';
 display: block;
 height: 300px;
 width: 200px;
}

This technique works just as well with CSS sprites, as long as the background-position is specified relatively to the CSS size (200 × 300 pixels in this case):

.icon {
 background-image: url(example@2x.png);
 background-size: 200px 300px;
 height: 25px;
 width: 25px;
 &.trash {
 background-position: 25px 0;
 }
 &.edit {
 background-position: 25px 25px;
 }
}

When using image sprites, consider any OS-specific limitations.

What to use it for? Websites that make limited use of the background-image property, such as those that rely on a single-image sprite.

HTML and CSS Sizing: Pros

• Easy to implement
• Cross-browser compatible

HTML and CSS Sizing: Cons

• Non-Retina devices have to download larger assets.
• Downsampled images might lose some of their sharpness on standard-density screens, depending on the algorithm used.
• The background-size property is not supported in IE 7 or 8.

Querying Pixel Density

Perhaps the most popular way to serve Retina-ready graphics on the Web is by querying the device for its pixel density and then serving assets accordingly. This can be done using either CSS or JavaScript.

Using CSS Media Queries

As of this writing, almost every major browser vendor has implemented a prefixed variant of device-pixel-ratio and its two siblings, min-device-pixel-ratio and max-device-pixel-ratio. These media queries can be used in conjunction with the background-image property to serve Retina-ready assets to high-density devices:

.icon {
 background-image: url(example.png);
 background-size: 200px 300px;
 height: 300px;
 width: 200px;
}
@media only screen and (-Webkit-min-device-pixel-ratio: 1.5),
only screen and (-moz-min-device-pixel-ratio: 1.5),
only screen and (-o-min-device-pixel-ratio: 3/2),
only screen and (min-device-pixel-ratio: 1.5) {
 .icon {
 background-image: url(example@2x.png);
 }
}

By using a ratio of 1.5 instead of 2, you can target other non-Apple devices with the same query.

What to use it for? Any website or app that uses the background-image property for graphic assets. Not suitable for content images.

CSS Querying: Pros

• Devices download only those assets that target them.
• Cross-browser compatible
• Pixel-precise control

CSS Querying: Cons

• Tedious to implement, especially on large websites.
• Displaying content images as backgrounds of other HTML elements is semantically incorrect.

Using Javascript

The pixel density of the screen can be queried in Javascript using window.devicePixelRatio, which reports the same value as its CSS counterpart. Once a higher-density screen is identified, you can replace every inline image with its Retina counterpart:

$(document).ready(function(){
 if (window.devicePixelRatio > 1) {
 var lowresImages = $('img');
 images.each(function(i) {
 var lowres = $(this).attr('src');
 var highres = lowres.replace(".", "@2x.");
 $(this).attr('src', highres);
 });
 }
});

Retina.js is a Javascript plugin that implements roughly the same technique as described above, with some additional features, such as skipping external images and skipping internal images with no @2x counterparts.

Lastly, it is worth noting that devicePixelRatio is not entirely cross-browser compatible.

What to use it for? Any website with content images, such as landing pages and blogs.

Javascript Querying: Pros

• Easy to implement
• Non-Retina devices do not download large assets.
• Pixel-precise control

Javascript Querying: Cons

• Retina devices have to download both standard- and high-resolution images.
• The image-swapping effect is visible on Retina devices.
• Does not work on some popular browsers (such as IE and Firefox).

Scalable Vector Graphics

Regardless of the method used, raster images remain inherently constrained by their bitmap resolution; they were never meant to be infinitely scalable. This is where vector graphics have the advantage, being a future-proof way to “Retinize” your Web graphics.

As of this writing, the vector XML-based SVG format has cross-browser support of more than 70% and can be used in several ways on the Web. SVG images can be easily created in and exported from a number of vector-graphic editors, such as Adobe Illustrator and free alternatives such as Inkscape.

As far as Web design goes, the most straightforward way to use SVG assets is with the HTML img tag or with the CSS background-image and content:url() properties.

<img src="example.svg" width="200" height="300" />

In the example above, a single SVG image can be used as a universal asset, scaling infinitely up or down as required. This not only saves precious bandwidth (most SVG files tend to be smaller in size than standard-resolution PNGs), but also makes your graphic assets much easier to maintain. The same would apply if used in CSS:

/* Using background-image */
.image {
 background-image: url(example.svg);
 background-size: 200px 300px;
 height: 200px;
 width: 300px;
}
/* Using content:url() */
.image-container:before {
 content: url(example.svg);
 /* width and height do not work with content:url() */
}

If you have to support IE 7 or 8 or Android 2.x, then you will need a fallback solution that swaps SVG images with their PNG counterparts. This can be easily done with Modernizr:

.image {
 background-image: url(example.png);
 background-size: 200px 300px;
}
.svg {
 .image {
 background-image: url(example.svg);
 }
}

For best cross-browser results and to avoid some rasterization headaches in Firefox and Opera, make each SVG image at least the size of its parent HTML element.

In HTML, you can implement a similar fallback solution by adding a custom data attribute to your img tag:

<img src="example.svg" data-png-fallback="example.png" />

Then, handle the rest with jQuery and Modernizr:

$(document).ready(function(){
 if(!Modernizr.svg) {
 var images = $('img[data-png-fallback]');
 images.each(function(i) {
 $(this).attr('src', $(this).data('png-fallback'));
 });
 }
});

This HTML and JavaScript route, however, would not prevent browsers with no SVG support from downloading the SVG assets.

What to use it for? Any website or app. Suitable for icons, logos and simple vector illustrations.

SVG: Pros

• One universal asset for all devices
• Easy to maintain
• Future-proof: infinitely scalable vector graphics

SVG: Cons

• No pixel precision due to anti-aliasing
• Unsuitable for complex graphics due to large file sizes
• No native support in IE 7 and 8 or early Android versions

Icon Fonts

Popularized by Twitter’s Bootstrap, the technique of using @font-face with icon-based fonts has garnered a following of its own as a resolution-independent alternative to bitmap icons. The technique consists of using a custom Web font that replaces the alphabet with monochrome glyphs, which can be styled using CSS, just like any other text on the website.

There is no shortage of comprehensive, good-quality icon fonts that would cover most of your needs. That being said, importing a large font in half a dozen formats only to use a small subset of the icons is a bad idea. Consider building your own custom font with free tools such as Fontello, Font Builder or even Inkscape.

The most common way to use icon fonts on websites is by assigning an .icon or .glyph class to a particular HTML element — most often a <span> or an <i> — and then using the letter corresponding to the desired icon as its content:

<span class="icon">a</span>

After having imported your custom font using @font-face, you would declare it:

.icon {
 font-family: 'My Icon Font';
}

Another technique consists of using the :before pseudo-element and the content property, with a unique class for each icon:

<span class="glyph-heart"></span>

[class^="glyph-"]:before {
 font-family: 'My Icon Font';
}
.glyph-heart:before {
 content: 'h';
}

What to use it for? Websites or apps with a high number of icons, and for rapid prototyping.

Icon Fonts: Pros

• Future-proof: infinitely scalable glyphs
• Cross-browser compatible
• More flexible than graphic assets: can be used in placeholder text and other form elements, etc.

Icon Fonts: Cons

• No pixel precision due to subpixel anti-aliasing
• Hard to maintain: changing a single icon requires regenerating the whole font.
• Relies on semantically incorrect markup (unless used with :before or :after pseudo-elements).

Favicons

Favicons are getting their fair share of attention, being increasingly used outside of browser chrome as an iconic representation of our websites and apps. To make your favicons Retina-ready, export an .ico file in both 16- and 32-pixel versions. If you are using a Mac, you can create your own .ico files with Apple’s Icon Composer (included in the Graphic Tools in Xcode) or with Icon Slate, a paid third-party application.

A Glimpse Of The Future

Besides the techniques covered above, several other efforts are being made independently by organizations and individuals alike, not the least of which is Apple’s own -Webkit-image-set, introduced last spring. This proposal allows for multiple variants of the same image to be provided in one CSS declaration:

.image {
 background-image: -Webkit-image-set(url(example.png) 1x, url(example@2x.png) 2x);
 background-size: 200px 300px;
}

This technique does not, however, cover images inside img tags, and it is Webkit-only as of this writing.

Another notable effort is Scott Jehl’s Picturefill, an HTML and Javascript solution that makes heavy use of data attributes and media queries to serve different images in different media contexts.

<div data-picture>
 <div data-src="example.png"></div>
 <div data-src="example@2x.png" data-media="(min-device-pixel-ratio: 1.5)"></div>
 <!-- Fallback content for non-JS browsers -->
 <noscript>
 <img src="example.png" >
 </noscript>
</div>

Even if the markup puts you off, it is a good cross-browser solution to consider if you are dealing with few content images.

Last but not least, the ambitious picture element proposal aims to bring responsive images to the Web using a markup-only approach for multiple image sources, coupled with media queries that route each device to the right asset.

Closing Words

Like other major shifts the Web is currently undergoing, attaining resolution independence will be a long journey. As Web designers and developers, either we can sit down and wait passively for a convention to be standardized, or we can immediately start offering a pleasurable viewing experience to our users. Let’s get to work.

(al)