As you might have noticed from my previous writings on HTML 5 and CSS 3, I typically write about topics I wish to know more about, after spending a few weeks intensely googling learning about them. These two weeks, they happen to be SVG and Canvas. The interwebs are heating up with debates about the merits of each, and many are predicting a deathmatch. However, my research convinces me that each has its own purpose, but definitely their time has come.

What is SVG?

SVG is a language for describing two-dimensional graphics and graphical applications in XML. Some examples of SVG are the Wikipedia logo and this “Hello World” of SVG, a Tiger. View the source of those two SVG files to see how SVG looks like.

What is Canvas?

The HTML 5 spec defines it best: “The canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.”

This presentation by Mozilla’s Vladimir Vukićević, created in 2006, has a good explanation of the differences between SVG and Canvas, namely:

• SVG is XML based. This means, every element is available within the SVG DOM (useful when you want to attach javascript event handlers for an element — say you want to make the SVG tiger’s muskers twitch if you click on it). Canvas is not XML based.
• Canvas is rendered pixel by pixel. SVG is a bunch of vectors and needs to be manipulated as a group of shapes. An analogy in the Photoshop world would be, creating a rectangle using the “shape” tool in vs. using paintbrush.

Who Will Win?

Even though they are quite different in nature and purpose, there are several things that can be done using both Canvas and SVG. The recent popularity of the Canvas element seems to make some people sound the death knell for SVG. But, from what I have gathered, this is far from the truth.

Canvas is as good as an image — except it can be manipulated pixel by pixel. Right now, Canvas element cannot support event handlers (e.g. have a 20x20px wide rectangle within a canvas be clickable). SVG does.

Canvas, in its current state is not accessible. SVG however is quite accessible.

All this might change, as there is a task force that is looking into a Canvas 2D API. The very changes that might apply to Canvas might even get applied to the image element in future versions of SVG — which would a big win.

There are, however, significant performance differences between Canvas and SVG. The outcome of the experiment described in the previous link is that, Canvas is more suitable for a graphics-intensive game where many objects are redrawn frequently (like this Super Mario game), while SVG is best for applications that involve large rendering areas (like Google Maps).

Can I use them now?

Yes, you can. There are many initiatives to enable browsers which don’t support SVG or Canvas to render them using other means. Google has an impressive SVG Web project that uses Flash to render SVG in browsers that do not support SVG natively. Raphael renders content into SVG or VML using javascript (it is NOT a javascript API for SVG or VML). For Canvas, Google has an explorecanvas library that uses VML (or Silverlight) to render Canvas elements (you simply need to include the excanvas.js file, and it should work) in Internet Explorer.

Mark Pilgrim, as usual, has written an excellent article on how to use Canvas element, which is part of his book on HTML 5.

So, really, who wins?

Both. These are exciting times for SVG and Canvas. We finally have a native alternative to Flash for basic animation needs. Keep your eyes peeled on the HTML mailing list for breaking news. Or you can hear about them a few seconds later on my Web Development Twitter Stream.