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.

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.

We all know about the CSS sprites technique. (If you don’t, then have a quick read through Sven Lennartz’ article1. And Louis Lazaris points out its pros and cons2.) 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:

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:

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 Gecko3-based browsers.

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.

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.

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 sizes4.

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

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.

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.

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 Backgrounds5,” which explores more practical examples. For more ideas, see Alex Walker’s article “A Farewell to CSS3 Gradients6.”

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 demo7 demonstrating a combination of all the techniques mentioned above.

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?8, 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 support9 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.

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 technique10 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 Modernizr11 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.

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.

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 consistently12proved13slower14 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.

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.

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ş17 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 Coyier18.

Dingbat Web fonts19 and look-a-like Unicode glyphs are two interesting alternatives for vector icons, both with accessibility and semantic challenges. Jon Hicks has a write-up20 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.

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.

Related Articles

Alex W

Very interesting article..I’ll definitely have to give SVG more of a chance than I have been :)

Before people blow the comments up with “Blah Blah, not going to use it because it’s not fully supported, blah blah blah”, it’s worthy to note that most of new technologies will always be this way. It’s best to at least start learning and utilizing them in personal projects, so when they are supported, you’re already ahead of the curve and don’t have to spend weeks learning it. Something to think about.

Also, David, you may be aware, but in your CSS for the Sprite technique, you can condense it a bit more than you did.
You have:

SVG Nerd

Inkscape is pretty good, but it has some annoying habits. For one, it takes all the attributes like fill, stroke-width, etc, and sticks them in a style attribute. That totally blows away your ability to style your SVG with CSS. Fortunately, there’s an “Optimized SVG” format you can choose in the save as dialog to fix that. You’ll probably still want to optimize a bit more in a text editor though. Values like x=”0.500000000001″ can be quite unsightly.

SVG is awesome. I’ve got 24 site icons so far that gzip to about 5kb. I had intended to use the SVG element instead of making the file a sprite, but Webkit has a 5 year old bug (#12499) that prevents using the use element with external files. Bummer… :-/

Firefox and Opera handle it nicely. Opera even supports xpointer. And I don’t even care if IE can render it or not. But there’s webkit… So, it looks like I’ll need to use the more complicated sprite approach and be forced to remember where my icons live in a grid… :-(

Oh well, that will ‘bloat’ up my icons.svg file to about 6kb gzipped :-) Can’t be helped. Thanks for the article to raise some SVG awareness David.

Valentin Ganchev

Thank you for the great article! It really explains a lot how SVG is indeed a more sensible alternative to some existing techniques. However, I do have a somewhat related question to the matter.

You mentioned that you created your SVG file in Illustrator, but is there another program for creating SVG files or is in your opinion Illustrator the best one? Frankly, I don’t have the time nor the patience to create SVG files by hand.

John P. Bloch

I’ve used Inkscape, a free and open source alternative to Illustrator. Never having used Illustrator, I can’t speak to how they compare. I can say that it worked well enough to make vector graphics, although the learning curve is very steep.z

My suspicion, though, is that Inkscape does not really compare to Illustrator as far as quality and usability.

Jason Simanek

When it comes to screen graphics, Illustrator doesn’t have much to offer over Inkscape. Except for a really big price tag.

Not to start a flame war, but Inkscape has very good quality and its user interface could be argued as even easier to understand than Illustrator’s, depending on how familiar you are with the Adobe user interface.

Inkscape is also built around the SVG standard. It is actually a WYSIWYG for writing SVG. Inkscape files are SVG files. Illustrator can export to SVG, but when saving to SVG for live website use remember to use the right settings so that the Illustrator binary blob is excluded from the SVG file.

The real strength of Illustrator at this point in time is obvious in its support of CMYK color mode, mesh gradients (though that’s coming to Inkscape soon) and sophisticated typesetting features as well as being a widely used application, which is important if you plan to collaborate with professional graphic designers.

There are probably many other important features as well, since Illustrator has been in existence for decades. But I wanted to make it apparent that Inkscape is a very capable tool for creating high quality graphics.

1

12

easwee

Actually Inkscape is much more usable for this task than Illustrator. It supports all typical vector editing tools, it exports to .svg and what totally surpasses Illustrator – you can create a custom font directly in Inkscape (dingbats on the fly!) AND it has a SVG text editor where you can directly edit the svg nodes.
Not to mention that Illustrator (I use CS3 since I can’t afford to upgrade each year) crashes a lot on Windows – while in Inkscape I haven’t had a single crash since I’m using it.

So I would say – for creating svg graphics – specially for preparation of files – Inkscape wins.

Illustrator users will have problems with the interface for sure since it is a bit different, but for me it’s totally irrelevant – both are equally usable (I used both programs for the same amount of time more or less and didn’t have problems with any of interfaces).

Gordon

I’d say that until Internet explorer hits > 50% for versions 9 upward, browser compatibility is still going to be a major limiting factor. Even at 50% that will still mean a significant chunk of your userbase won’t be able to see your fancy resolution-independent SVG files.

That’s not to say it’s not an interesting technology, of course, it certainly is and it’s something the web had needed for a long time. I’m just saying we’re far from the point where we can bin all out PNG/GIF/JPEG files without consequence.

0

16

Sebastian

@Gordon: «until Internet explorer hits > 50% for versions 9 upward, browser compatibility is still going to be a major limiting factor.»
Around 2004 all the time Acrobat was installed, in the browser was placed the SVG plug-in. The percentage of browser with Acrobat plugin (and SVG) was around 96%.
Still SVG had no whatsoever traction. The w3c specification for SVG was the same of today.
The cool stuff was CSS and its tricks and hacks.
Then Adobe bought Macromedia and the Adobe SVG plugin has gone.

Donovan

Gordon I think that would have been a valid point a year ago but since chrome has taken over ie’s title as marketshare leader and then you throw all the other browsers that support SVG the gap just gets bigger.

Sebastian

David, I think you get the SVG perspective wrong.
You can use the CSS to “style” the SVG file itself.
The separation between design and content can be total.
Scenario: you design all the user interface in SVG for an unrest client. When the client want to change the all the colors, all your work is change the value of an attribute.

Sebastian
PS
I invest too much time SVG ten years ago. With my disappointment, it does not pay off.

deborah

Damon Muma

I think under ‘browser support’ you pretty much identified why they’re ‘one of the most underused technologies in website development today’.

Without simple workarounds for unsupported browsers, it seems like more trouble than its worth. So yeah great idea, but it’s not nearly ready for us to be worrying about it when making websites. Hopefully in a couple years they’ll be worth paying attention to.

Good to have svg on radar anyway

0

22

Sean

He did mention using Modernizr in the article to test for SVG support, i think thats about as simple a workaround as you could ask for, at least when your referencing SVG files in your CSS, obviously its not as simple if your linking SVG in your HTML

Moiz Farooqui

Jimmy

The idéa is not bad… might even come in handy some day. But i think i would rader go with the @font-face :before style and css3 stuff. b/c you get more opportunities with font-face, color, text-shadow, hover and so on. when the site owner turns out the want to change the color scheme it would be easy to just change color. Or if they want diffrent teams.

I also belive the Voice Speek have to adopt to the the web a bit more. or that the W3C can come up with something both can agree on.
I hope i someday see a new global attribute to all elements that’s called “icon” (simular to the data-icon”) that is not spoken. that could aswell be started to use now and not about 5 years when all browser have included it.
You would also need something lik icon-before/after=””

You must admit, icons is very common. so its now time to approve it in a way its semantic and easy to use.
prehaps you also could do in your css code:

voiceSpeeak: none;

0

30

Jimmy Breck-McKye

Another thing – don’t forget that SVG files, being XML, can be generated by Javascript. If your application allows users to set their own colours or branding (like some kind of white label webapp), that could mean UI elements that adapt accordingly. In the example above, imagine the grey icons taking a coloured hover state that matches the client’s branding. Or an application that uses a large gamut of colours for meaning, which would otherwise need to send absurdly large sprites.

Abbas

Andrew Pendleton

You say “mobile browser support is also pretty much across the board,” but this unfortunately isn’t really the case, yet. As your linked chart says, Android doesn’t include in-browser SVG support until Honeycomb, and as that never shipped on phones, only the very newest Ice Cream Sandwich phones (pretty much just the Galaxy Nexus at this point) support SVG. As Froyo (2.2) and Gingerbread (2.3) are by far the most common Android versions in current use, you definitely can’t assume that Android users will see your SVGs.

0

34

David Bushell

Thanks for the clarity Andrew, I should have been more specific in regards to “latest versions” for mobile support. As always the right progressive enhancement would make sure non-supporting browsers don’t break (which to be fair is tricky and not without its caveats when SVG is concerned).

0

35

Charlie Heath

It is worse than that; the earlier Android browsers will display any SVG as a white background area, so if you have white text color they simply disappear on Android. I think I will handle this by detecting Android <= 2.3 either on back end or javascript and overriding the elements which have SVG declarations.

David Bushell

To be clear I wouldn’t suggest drastically scaling down a very large and detailed icon for the reason you’ve highlighted, and also because the file size would be needlessly large. In my demo I used icons designed for small sizes and they look great even on low PPI screens. The issue of image blur on varying PPI and zoom is resolved, though the “small” vector designs would be of little use at large sizes. So in that case multiple versions would still be required (a logo or app icon, for example). At least until bandwidth is free and browsers can magically render while removing the right details!

0

38

Soso

No, your Icons are a great example: If you would have cleaned them up right in illustrator, they are a good example of clean, pixel-perfect icons that we are used to see everywhere today. And you scaled them up by exactly 200%. Very easy to render.

But if you scale the icons/zoom-in by a uneven factor (1,5x oder 2,358x) you get blurry lines or even broken lines. When I zoom into your example in Firefox by one step (guest it’s 125 or 150%) your envelope has 2 different line thicknesses and some lines on the printer disappear at all.

On high-dpi-displays I don’t see a problem. But on a regular desktop-display it is massive. The (vector-)render-engines in modern browsers are simply not there for quality but only speed. So, with this result, I can’t offer my clients a universal SVG-option, but only on mobile.

Today, too many websites are still inaccessible. In our new book Inclusive Design Patterns, we explore how to craft flexible front-end design patterns and make future-proof and accessible interfaces without extra effort. Hardcover, 312 pages. Get the book →

Meet the new Sketch Handbook, our brand new Smashing book that will help you master all the tricky, advanced facets of Sketch. Filled with practical examples and tutorials in 12 chapters, the book will help you become more proficient in your work. Get the book.

Meet SmashingConf San Francisco 2017, featuring front-end ingredients, UX recipes and nothing but practical beats from the hidden corners of the web. Only practical, real-life techniques and recipes you can learn from. Get your ticket now!