By Meitar Moscovitz

What Everybody Ought to Know about Using SVG Right Now

By Meitar Moscovitz

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 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:

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. There’s also a commercial product called InputDraw.
  • 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:

  1. Provide a cross-browser JavaScript API for writing SVG commands (just as libraries like jQuery do for DOM manipulation).
  2. Write the appropriate vector graphics language to the DOM nodes based on your commands (SVG to conforming browsers, VML to Internet Explorer).
  3. 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!

  • Jeff Schiller

    Great article but a couple things:

    a) Adobe did not create SVG, the W3C did. The Adobe did champion it for years until they bought Macromedia.

    b) You didn’t talk about support in editors. Here are a few: Inkscape, Sketsa, Adobe Illustrator, SVG-edit (disclaimer: I am a lead on SVG-edit)

  • Good points, Jeff, thank you! As far as I was aware, Adobe was the strongest champion of SVG for a long time, and their participation in SVG was very significant, which is why I said that Adobe is the originator of the technology, but I realize now that this was an oversimplification that could have been misleading. I’ve updated the blog post to reflect that.

    As for editors, I think there are a few different audiences for SVG. I’m speaking more toward developers over artists, so I left the discussion of GUI editors for the SVG primers I linked to in various places. Again, though, thanks for adding the helpful info!

  • thank you thank you thank you! I have just bought 2 books on SVG and was wondering if that was pointless when I read that MS is STILL not supporting it & doesn’t even intend to in ie9.
    brilliant post.

  • Jeff Schiller

    @stikkybubble There is significant evidence that Microsoft is considering SVG for IE9: they were a gold sponsor of SVG Open 2009, they have joined the SVG WG (and are asking the questions that an implementor would ask), and they are putting significant amount of work into improving graphics performance in IE9.

  • Q.E.D.

    Can SVG be turned into VML using XSLT in IE?

  • Anonymous

    Adobe was the strongest champion

  • jim

    Now that i4i has bested Microsoft (vis-á-vis the recent i4i XML patent lawsuit*), and picked up $290MUS in the bargain, do you see them funding any further attacks on other entities utilizing XML / XML-based formats / tools (eg, SVG since it, and presumably it’s tools, are XML-basd)? If so, how? Just curious.

  • Ben

    I think the most exciting use of SVG is to use it for background images. The native scalability is just awesome. You don’t have to rely on multiple elements or multiple background images in order to have a scalable, visually pleasing layout. Opera has had support for this since at least 9.0 and Webkit just added it recently. I don’t know why Firefox hasn’t implemented it yet.

  • Justen

    I’ve been using SVG in pet projects ever since you guys brought up Raphael. I’m finally going to get the chance to use it at a production level in the next couple months, which I’m extremely excited about. Thanks for the heads up about MS joining the SVG working group, maybe we’ll see some support in IE9 (who’d have imagined 3 years ago that Microsoft would start taking standards seriously…).

  • Can SVG be turned into VML using XSLT in IE?

    Yes, actually, it can, Q.E.D., and that’d be another way to support IE today. I didn’t mention it in the overview list because I imagine that a very small proportion people who are new to SVG have enough XSLT experience to follow that route, if any. You raise a good point about the possibility, though!

    Now that i4i has bested Microsoft (vis-á-vis the recent i4i XML patent lawsuit), and picked up $290MUS in the bargain, do you see them funding any further attacks on other entities utilizing XML / XML-based formats / tools (eg, SVG since it, and presumably it’s tools, are XML-basd)? If so, how? Just curious.

    That’s a really good question, Jim, and unfortunately I can’t speak to it very well. I’m not a lawyer and I don’t understand the way software patents “work.” (They arguably don’t even “work” in the first place!)

    That being said, if nothing else, this is all the more reason why learning how to hand-code is a good thing. I would find it hard to believe that anyone would find legal trouble with someone using, say, a keyboard as their “tool” for creating “custom XML.”

    [M]aybe we’ll see some support in IE9.

    Here’s hoping, Justen!!

  • rodry

    After many years svg seems to take new life!
    I create this svg web application seven years ago…2003
    For IE it’s always necessary Adobe plug-in :-(
    In Chrome and FF render is good

  • Great article, I really enjoyed it. The article is very well written, got me inspired again…

    Here are some Javascript SVG Libraries I’ve found

  • Sergey

    Maybe worth mentioning, Ample SDK makes SVG usable in IE (as well as in other browsers) with support for DOM and CSS.
    Take a look at the example Worldmap interactive.

  • veikoh

    Why we forget the mobile space!!!
    SVG was working in those devices where Ikivo drivers where preinstalled in 2006. IN 2009 finally webkit with all the support of Nokia and Apple money got it work. And it worked with Opera at first place because young guy named Eric Dahlstrom wrote it as school project and Opera was thinking… it’s a good idea to get it integrate with our browser.

  • jon

    Came to know about SVG way back around 2002/03, where i’ve implemented it in a school project. Back then, Adobe used to be very supportive for SVG, they have creatd amazing sample application, sad to say they have since removed them from their SVG site.

    But i’ve to say that the adobe plugin is probably the best, it provides zooming and search capabilities which are the essence of SVG.

  • worxguy

    Perhaps I’m confused or missing the point. The article encourages us to “Just go pick up an SVG primer and start using the ‘Save as SVG’ option in your favorite graphics application.” That’s for me, since I’m more of an end user than a coder. But, I’ve not been able to get that process to work. I created a simple logo in Inkscape and saved it in svg format. Yet, I can not get logo.svg to display in any browser using Raphael’s image placement code. The exported Inkscape logo.png will display, using the same Raphael code, but it gets a bad case of the jaggies. Inkscape says this is a browser issue. Therefore, I had to run Inkscape’s logo.png thru Gimp to reduce the jaggies. So I ask myself: What’s the point, if I’m back to Gimp? What am I missing? I’m not up to speed on attempting to build the logo in raw or Raphael svg.

Get the latest in Front-end, once a week, for free.