Adventures with SVG (a lessons learned post)

Go into the open dessert. Draw a circle around you. All that is inside the circle represents your knowledge. All that is outside the circle represents that which you do not know. The line represents that which you know you do not know. What happens as you make the circle bigger?
— Unknown

I don’t remember where I first read a version of the above story. However, it rings true for my recent experiences. You see I wrote a simple jQuery plugin, and decided to use inkscape to generate the graphics used by it. I then discovered it was possible to animate the SVG files with javascript. Before I knew it I found myself wandering through a dessert awaiting the promised land of SVG. I’ve yet to reach the promised land, but I’ve learned a lot in the experience.

Lesson Zero: SVG is poorly documented on the web.

I need to qualify the section header a bit. The actual standard is pretty well defined. There are examples on the web, and w3schools has a section on SVG. However, SVG is not popular enough for you to be able to steal all your code from google. You will have to experiment to do a lot of simple tasks.

Lesson One: SVG has very html like DOM.

This one was a pleasant surprise actually. SVG elements have event attributes like onload and onclick. Animating is as simple as recursively calling a function via window.setTimeout(). You could call console.log() to trace your javascript’s execution via firebug or the chrome developer console. In general I was able to leverage a lot of the javascript experience I’ve had with html.

Lesson Two: I should be animating with SMIL instead of javascript.

I’ll call this a lesson I’ve not really learned. If I truely learned my lesson I would have learned SMIL and done my animations with it instead of javascript. However, I was more concerned in exploring what could be done by combining javascript and SVG than animating SVGs.

Lesson Three: SVG is inconsistently implemented in practice.

I’m not just talking about amongsT the browsers, but that too is a problem.

First of all, you need to use one of several plugins to render SVGs in Internet Explorer. IE9 will finally rectify that. The no longer maintained Adobe SVG plugin was the most popular IE plugin. However, the still alpha flash and javascript based svgweb by google is gaining popularity. That one has the advantage of not requiring any special software besides flash, which is probably already installed. However, it seems it does not support javascript embedded in the svg file.

Second, SVG support is inconsistent amongst opera, firefox, and chrome. Chrome has a nasty habit of not rendering svg embedded in html via an <object/> tag if the mime type is not properly set. I discovered this while serving html and svg through Cassini.

(As an aside, I have made available a modified version of Cassini on github so no one will have to suffer as I have.)

Third, inkscape, the editor I use to draw my SVGs, is not a complete SVG editor, and it implents several extensions to the SVG standard. The extended elements have not prevented SVGs I drew in Inkscape from being rendered in browsers since they have different XML namespaces. While I’ve discovered how to reference external javascript files in a svg through inkscape, I have to use a separate text editor on the SVG files to embed javascript in the document.


My first conclusion is SVG is not quite ready for prime time as a deploy directly to the web technology. However, there is enough buzz happening that early adopting might be prudent for some scenarios. Browser support is improving, and the tools are improving.

My second conclusion is that SVG is ready as a “mastering format,” like PSD, XCF (gimp native) or Illustrator. If you want to draw with a rector tool, and then render to a bitmap, SVG is a solid format. Inkscape is a good editor.

My third and final conclusion, is that the desert of SVG is very big, and my circle in the sand is quite small.