Scalable Vector Graphics (SVG) consist of circles, rectangles, and paths created in XML and combined into drawings on web pages. You can apply solid colors, gradients, and a sophisticated number of filters to SVG—although not all browsers implement all filter types. You can incorporate text, as well as images, and you can copy and clone your SVG as much as you want. Mostly, we use SVG for graphics programs, charts, illustrations, or animations. However, we can incorporate SVG into a site’s overall design—it’s a wonderfully versatile, web design capability that’s fun to use. In this introductory article, I’ll cover some important considerations for working with SVG, including browser support and accessibility. Read Part II to learn how to find and adapt SVG you can find online, or how to create your own SVG drawings and add them to your web pages.
SVG in the wild#section2
Several people use SVG for site design—mostly for topic icons. For instance, Sam Ruby, current HTML5 Working Group co-chair, uses SVG to annotate his weblog posts with topic icons. Erik Dahlstrom, from Opera, does the same, as does Jeff Schiller at Codedread. Jeff goes beyond icons, and incorporates SVG into his fisheye menu bar, as well as his website outliner graphic. The Emacs for Mac OS X web site is mostly SVG; resize the web page to see SVG scaling in action.
I’ve used SVG to provide a gradient color selected from a currently displayed photo (reload the page a couple of times to see the effect), as a whimsical background element, and to provide an overall theme to unite my websites.
When you can, and can’t use SVG#section3
You can use SVG anywhere you use a GIF, JPEG, or PNG. With SVG, you’re providing drawing instructions rather than a bitmap.
SVG, being a vector graphic, can scale to fit the web page, while bitmap images such as JPEG and GIF cannot, or at least, can’t scale cleanly. This scalability is particularly handy when users access web pages from devices as small as the iPhone, and as large as a 32-inch monitor. To demonstrate, Figure 1 is a snapshot of the EMACS for OS X website when first opened in the browser. Figure 2 shows the same site, but with the browser window collapsed vertically. Note that the image shrinks to fit the page, scaling in such a way that the image’s perspective is always preserved. No matter how large the page, the image scales accordingly, without pixel breakup.
Fig 1. showing snapshot of EMACS for OS X website
Fig 2. shows the same site, with different browser window size
SVG can also be bandwidth friendly. It doesn’t matter how large the graphic gets, the XML that describes the graphic is the only thing transmitted to the client. From millimeters to meters, the graphic bandwidth requirements are the same, which makes SVG an attractive alternative when a graphic needs to fill the background of a web page, without having to repeat.
As fun as SVG can be, there are circumstances where you won’t want to apply it. For instance, you can convert a photo to an SVG drawing, but the conversion will never be to the pixel level. In addition, client devices will bog down if the graphic is too complicated. I converted a rather complex JPEG image into an SVG file that I use for testing. Not only did it crash the first beta release of Chrome, the browser crashed my computer just trying to process the SVG.
So no, SVG cannot replace photos or complex images, but everything else is fair game. Before we get our hands dirty in Part II of this article, it’s important to learn about SVG browser support and accessibility.
The major browsers—Firefox, Chrome, Safari, and Opera—support SVG, either as a file loaded into an object, or embedded directly in XHTML. Jeff Schiller, whom I mentioned earlier, maintains a graphic that details SVG support in the various browsers.
As I just mentioned, most of the major browsers support basic SVG. The one significant exception is Internet Explorer.
Internet Explorer and SVG#section5
I’m encouraging you to use SVG, but as shown in the last section, one major browser currently does not support SVG, and that browser is Internet Explorer. Luckily for us, IE’s lack of support for SVG is no longer the barrier it once was.
Libraries such as SVGWeb, Ample SDK, and Raphael enable support for SVG in current and past versions of IE. In addition, the HTML5 specification enables embedding SVG in HTML, where before it was only supported with XHTML. This increased document type support, plus the recent news about Microsoft joining the W3C SVG working group, gives us hope that, eventually, IE will have direct support for SVG—perhaps even in IE9.
In the meantime, mobile device access to the web is increasing, and none of the popular handheld devices are dependent on IE. Additionally, the recent popularity of minimalist design can be used to effectively introduce SVG into your websites. If a website has an attractive but minimalist design, SVG can be added as a fun annotation, and it doesn’t matter if the SVG is displayed or not. The SVG-using sites mentioned earlier either provide a fallback graphic if SVG isn’t implemented, look fine without the SVG, or ask the reader to consider moving to an SVG-aware browser. (Hey, don’t knock the last one. This approach worked for IE 4.x in the browser wars over ten years ago.)
What about Accessibility?#section6
SVG has the ability to provide short and long text alternatives for images. Since it is based in a markup language, you can easily add both title and description via the
desc elements, as shown below. Unfortunately, screen reader support for these elements remains poor, creating a challenge for sites that use SVG where accessibility is a requirement.
<title>Chimp on a tightrope</title> Older chimp walking across a tightrope between two trees at the St. Louis Zoo
Title is typically pulled out to be the document title in a stand alone SVG. Both
desc can also take more complex markup from other namespaces. In addition, for more complex metadata, there’s the
metadata element, which can contain RDF/XML for things such as copyright and author information.
Because screen reader support for SVG is poor, you can use server-side processing or XSLT to take accessibility information from embedded SVG, and generate content in HTML from the
metadata elements. For background and decorative images, you might want to minimize the amount of markup in the SVG, and in these situations, the
desc elements may not be needed.
For more on accessibility and SVG, read the original Note on SVG and Accessibility at the W3C, Henny Swan’s “Just how accessible is SVG?,” and the SVG Accessibility Guidelines for SVG 1.2.
Ready to Dive In#section7
Now that we’ve covered the important stuff, such as browser and accessibility support, as well as some of advantages of using SVG, it’s time to get into the fun bits. The second article describes how to incorporate SVG into your pages so that the design works for all browsers; where you can find freely available SVG files; and how to use one of the more popular, and free, vector graphics tools to modify, or create, your own SVG designs.
12 Reader Comments
As much as I dislike IE, this intentionally misleading section grates. You can’t list Chrome and Opera as a ‘major browser’ and not IE, and then a few paragraphs down the say ‘there is one one exception…” I find that approach dishonest, you should say it straight up.
I enjoyed the next, hands on article more.
I’m going to say something horrible, but let’s face it, as we probably will meet it : when SVG will be in all major browsers, what about replacing html by svg and directly write php/rails/whatever code in svg templates?
I like the fact that you instantaneously draw the borders of good usages of svg, but maybe it will have to be far more stressed.
I pretty sure lots of people will be delighted to directly put online what they’ve draw in illustrator/inkscape with a few more lines of code, and it will be the end of separation between content and styles.
I agree with fritz’ comment: that statement certainly stood out and started ringing alarm bells. I suggest the word “major” be replaced with the word “good”; the statement would then read perfectly 😉
Fritz, your point is good, and originally the editor had it first. I switched the two. My only excuse is I didn’t want people to immediately dismiss SVG because of the current lack of SVG support. Mea culpa.
Having said this…please don’t dismiss SVG just because of current issues with IE 😉
These articles are a good introduction to the subject with well-chosen examples.
Charlie, it’s not really either/or with SVG and Canvas. The two technologies are complementary rather than competitive.
Both tools have their uses. I’ve used both, and cover both when I write on web graphics. I’m glad they both have a home in HTML5, and hopefully someday, IE.
Every time we work around IE’s shortcomings, we allow Microsoft the wiggle room to not fix those shortcomings. (because everytime we pander to IE’s failings, Microsoft _doesn’t_ hear complaints from people about their poor browsing experience)
And to list “major browsers” omitting the only one with >50% market share is … beyond misleading. It makes you look stupid.
Use the wonderful modern features, and have a fallback for IE that just _doesn’t look as good_. Thats the only way pressure is brought to bear on MS to raise their game; when it becomes widely known that the best browsing experience is ‘anything but IE’ – thats when MS will wake up and play the standards game.
By the nature of *SVG’s*, i’m urged to use them for clients’ *web design*. It’s *scalable, lightweight*, everything you need. But somehow as always, IE manages to ruin anything beautiful that ever existed… 🙁
I’m just hoping vectors get more support in the future so i wouldn’t have to become best pals with photoshop again. He’s a betrayer 😛
Nice article overall
Firstly let me say that this is a great article and very informative.
I’d like to look at a slightly tangential discussion though, you make the statement : “creating a challenge for sites that use SVG where accessibility is a requirement”. I can’t imagine a site where accessibility isn’t a requirement, can you clarify what you mean?
Just a quick note to say that Microsoft has confirmed today, with the alpha preview of IE9, support for SVG. Not only SVG, but CSS3, HTML5 new elements, as well as parsing XHTML as application/xhtml+xml.
Sorry, typo: that’s IE9, not IE(
I usually design for Mobile and smart devices. as different mobile devices have different screen sizes, using adaptability felt like a good option. I created an adaptive layout, with the fonts and everything sizing with the screen size through css and some neat jquery. When i had to have some icons, i thought of using SVG and they turned out beautifully. Scaling with the page width etc.
I was rudely interrupted with my design dream, when i found out on previewing that the svgs were NOT WORKING on andriod. and now im stuck. I guess andriod just decided not to support svg for some reason. Its working find on all IOS devices though.
The only version of andriod that did support was the ice cream sandwich but thats no good as a lot of users are still using older versions and not having andriod support means i have to think of another way to do this without SVG. any ideas ?
Got something to say?
We have turned off comments, but you can see what folks had to say before we did so.
More from ALA
Personalization Pyramid: A Framework for Designing with User Data
Mobile-First CSS: Is It Time for a Rethink?
Designers, (Re)define Success First
Breaking Out of the Box
How to Sell UX Research with Two Simple Questions