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.
Browser Support#section4
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 the graphic shows, most of the major browsers support basic SVG. This includes support for fonts, images, graphical elements, such as circles or paths, as well as gradients and some of the filters. Only the more esoteric features aren’t supported. However, the lack of the more advanced features shouldn’t influence using SVG in site design, as I don’t recommend using overly complex SVG images as a page background. The more complex the image, the longer it can take for the browser to render. Think twice, too, before using animated backgrounds, as many people get irritated with too much page movement, especially movement they can’t control by turning JavaScript off.
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 title and 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 is typically pulled out to be the document title in a stand alone SVG. Both title and 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 title, desc, and metadata elements. For background and decorative images, you might want to minimize the amount of markup in the SVG, and in these situations, the title and 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.
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.
Surely using the browser canvas directly is where a lot of the interest is now going? SVG’s only advantage over other vector formats is that it is open. This comes at the not inconsiderable advantage of XML as the serialisation format. I currently have an application that uses Graphviz to turn dot to SVG which the browser then parses and renders. But now there is a javascript library (http://code.google.com/p/canviz/) that renders the dot directly on the canvas. Great separation of client and server and much more efficient data transfer (JSON is much more compact than XML) and easier event handling for animation. That would leave illustration for SVG but why even that? Any application that can generate the XML for SVG can just as well generate the javascript for the canvas.
Charlie, it’s not really either/or with SVG and Canvas. The two technologies are complementary rather than competitive.
If I were doing a frame based animation, I’d be more likely to use Canvas, which is an in-memory graphic. However, for site design, I’d rather stay with SVG, which works whether JavaScript is turned off in the browser or not. We can also do things like copy graphics from online sites, like the ones I mention in the second article, and modify and re-use for our needs using graphics tools, such as Illustrator and Inkscape. You really can’t do anything like that with Canvas.
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
Tasarim
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 ?