What Everybody Ought to Know about Using SVG Right Now

Often, the biggest problem with a really good thing is simply that not enough people know how to leverage it. Of course, this is a sort of chicken-and-egg problem with which Web developers are painfully familiar. Is it up to manufacturers to support a technology before it gets used, or is it up to developers to implement stuff using a technology in order to get manufacturers to support it?

Such is the case with SVG, a fantastically capable, albeit not entirely cross-browser compatible, graphics technology. Not being a browser manufacturer myself, I’m now of the opinion that if there’s a good thing out there, I might as well just start using it. Perhaps if everyone simply took it upon themselves to advocate good technologies this way, fewer people would care whether the industry should be starting with the chicken or the egg.

Regardless, when I was beginning to feel intrigued by SVG and its potential, I wish someone would have given me a single big-picture overview of the things I needed to know. Thankfully, after a few years, that someone who came along was Dmitry Baranovskiy. The most important thing he told me (and the rest of the audience at Web Directions South) was that I could start using SVG in production projects immediately.

What is SVG?

For those who don’t already know what SVG is, allow me to briefly back up to explain why SVG is so, so good. In a sentence, according to Adobe, who was a very early champion of the ~~originators of the~~ technology:

Scalable Vector Graphics (SVG) is a text-based graphics language that describes images with vector shapes, text, and embedded raster graphics.

Okay, but what does that mean?

Scalable means that the technology is natively resolution-independent.
Vector means that image data is described using relative mathematical coordinates. To borrow Leigh Dodds’ words from this early XML.com article:
The <path> element defines the shape of an object using instructions similar to those of a pen plotter, e.g., move here, draw, move here, etc. Here’s an example taken from the spec:
```
<path d="M 100 100 L 140 100 L 120 140 z"/>
```
That attribute stuffed full of letters and numbers are coordinates on the SVG canvas, which is analogous to the coordinates in the viewport of a browser window. The M command in the <path> element’s d attribute is the “move to” command, the L is “line to,” and the final z is “close.” Here’s a short and sweet visual guide to SVG path notation.
Finally, Graphics means that it’s used to create images, but also means it natively supports importing and displaying bitmapped graphics and videos, using its <foreignObject> element. You can think of this feature in similar terms as the more familiar <object> or <embed> elements in HTML.

Why use SVG?

All right, so now that we know what SVG is, why does all of that scaling, vector-y stuff make SVG so cool? There are many reasons, but the top three I think are most compelling are:

SVG is very highly searchable because SVG images are really just interpreted XML files (just like web pages are interpreted HTML files), and XML is simply plain text. If you remember back to the heyday of the “Flash website,” you’ll no doubt recall what a nightmare Flash’s proprietary, binary file format was for search engines, which have has always preferred text. Over time, Flash developed all kinds of special features to bolt on accessibility for search engine spiders and human users alike, but if SVG had been dominant, that particular problem would’ve been moot.
From very early on, SVG was designed in a modular fashion, parroting the design philosophy of its “parent” technology, XML. Practically, this means that SVG provides relatively strong mobile support because it comes in a few different flavors that are interoperable with one another. It does this by defining profiles to support low-end devices with reasonable quality while still providing high-fidelity content. Y’know, just like the Web was always intended to do.
If you care about such things (and I do), SVG has been an open standard well before Flash was. Even if you don’t care about open standards, there are still many other reasons SVG is important to the Web.

As any good developer knows, when you layer higher-level capabilities on top of a solid foundation, it becomes much easier to iteratively introduce enhancements as newer features are introduced. If you let it, SVG can be that foundation of “flashy” effects.

Browser Support for SVG

The story of SVG support largely mirrors the frustrating story of the browser wars. Thankfully, however, browser support for SVG has been increasing for a long time, and within the past couple of years it’s picked up considerably. Here’s the support picture in a nutshell:

Opera has virtually full SVG support and has had some amount of support since Opera 8.
Gecko has had increasing support since 2005. Today, Firefox supports a significant majority of SVG features.
WebKit has had increasing support since 2006. Today, any WebKit-based browser like Safari has a totally usable implementation.
Internet Explorer (still) has no native support. That said, Microsoft has just recently joined the W3C’s SVG Working group, so there may yet be some hope.

If you don’t have to (and don’t want to) care about Internet Explorer, then there’s nothing more you need to worry about. Just go pick up an SVG primer and start using the “Save as SVG” option in your favorite graphics application.

However, most of the time you’re going to need to do something to help bring Internet Explorer along for the ride. So what can you do about IE today? Here’s a bird’s eye breakdown of the options you’ve got to deal with IE’s frustrating lack of support:

Rely on HTTP content negotiation to serve SVG to supporting browsers, and raster images to Internet Explorer. While this works reliably, it feels like 1995 again because you still need two separate pieces of content, unless you build one dynamically from the other. This is what Wikipedia does today.
Make users install plugins. Adobe has had one forever called the Adobe SVG Viewer. It’s pretty good, but was sentenced to end-of-life in 2007 and, well, it’s a plugin. (I’m not sure how Flash got away with also being a plugin, but that is besides the point.)
Relent and use Flash on the client-side, but revel in delicious SVG pureness for your source files. There are some attempts at making free software that uses SVG path data and passes it to Flash to render but these are still difficult to use.
Finally, and probably most compellingly, use a cross-browser API. It just so happens that there are quite a few of these that are free, open source, and very slick:
- SVG in The Dojo Toolkit seems solid, and for anyone who uses Dojo already it’s probably the best bet.
- svgweb is Google’s experimental library. (For obvious reasons, it’s enjoying the biggest hype right now.)
- RaphaëlJS, written by Dmitry Baranovskiy is my favorite cross-browser SVG toolkit, and one we’ve written about at SitePoint before. Since it’s a stand-alone library, you can actually mix-and-match it with your favorite JavaScript framework. In other words, you can take your pick of jQuery, YUI, Prototype, or another JavaScript framework, and just layer RaphaëlJS calls on top of it for all your SVG-related work.

How do SVG-writing JS frameworks work?

To support Internet Explorer and to add interactivity to the Flash-like effects that SVG can give your website, you’re almost certainly going to want to use a framework. But how do they work? It’s actually remarkably straightforward, all thanks to an earlier vector graphics language that Microsoft developed and still uses today, which the open SVG standard took many of its cues from: VML, or the Vector Markup Language.

SVG-writing JavaScript frameworks, therefore, all follow the same paradigm. Each of them essentially do this:

Provide a cross-browser JavaScript API for writing SVG commands (just as libraries like jQuery do for DOM manipulation).
Write the appropriate vector graphics language to the DOM nodes based on your commands (SVG to conforming browsers, VML to Internet Explorer).
Make you coffee. (Okay, well, not really.)

Hype it up

As you can see, there’s a wealth of information and no shortage of tools for helping you use SVG right now. Hopefully, we’ve already passed the tipping point. Moreover, the number of knowledgeable people able and willing to help you implement solutions in SVG is growing every day, and many are members of SitePoint’s own forums. So with all these resources under your belt, go out and start enjoying the possibilities!