Interactive Graphics on the Web.

The web has changed remarkably over the past few years. It is still everything it used to be - a great repository of information, but now it is also considered a viable platform for applications too. This would be all well and good except that these applications are built on top of the original capabilities of the browsers they run in, which were written to display static text and static images.

Thankfully there have been some major advancements along the way, JavaScript solved the last fundamental requirement by providing client side processing and control. CSS gave applications their own look and feel, and coupled with JavaScript enabled developers to create fancy menus and other controls. To my mind there are still two major omissions - decent two way communication with the server, and rendering of dynamic images. The first can be worked around with a little more bandwidth and processing overhead, to work around the second would require much more of both.

So there is this capability that some developers want, and some need, and it really needs to be supported across all the major browsers. At this point we can expect a standard to be drafted and then some implementations, and one day hopefully some implementations that fully conform to the standard. Of course, this being software, we might also get something implemented first, then standardized and copied elsewhere. Right now we have both, SVG has been around for years and is now supported by Firefox and Opera, the canvas element was a quick hack made in Safari (because they were worried about how hard it would be to implement SVG) and is now also seen in Firefox and Opera.

Safari will be getting SVG support in the near future, so as far as compatibility is concerned there is very little reason to choose either SVG or the canvas tag over the other. They are however fundamentally different, which will cause problems for anyone hoping to support both.

SVG is a persistent graphics framework, working in much the same way as HTML. An SVG document is described as a hierarchy of graphical primitives in XML. As with HTML this means that static documents can be rendered without any form of control language, but more interestingly for application developers the document is accessible to JavaScript, enabling dynamic changes and interactions on the client.

The canvas tag provides an imperative drawing mechanism, without any scripts running the element is blank. JavaScript can obtain a handle to the element and then issue drawing commands using the methods provided. This is exactly how drawing is done on most desktops, so would seem the natural choice for a developer moving their application to a web platform. But before siding with a little familiarity, there are a few more considerations to take into account.

Two of the most important criteria when choosing a graphics platform are performance and capabilities. This is where SVG triumphs because the odds were severly stacked in its favour. The web platform is not like the desktop platform where the application logic and the rendering are typically written in the same language. Today's JavaScript implementations are a good deal slower than native code the browsers are compiled to so any oppertunity to move the workload into the browser's core is benificial. With SVG the calculations of which part of the screen need to be redrawn, which elements are completely obscured and thus do not need to be drawn, and the hit detection to trigger events on mouse and keyboard input are all handled natively.

On the capabilities side it is the design process that SVG went through that makes it stand apart. Yes, it does have features that an application developer might not need, and might be hard enough to implement that it might not be well supported yet, but just beacause something is hard does not mean that it is not worth doing right. The implementors of the canvas tag were obviously solving a very real and immediate problem, which accounts for one no text rendering, at all. There is a comment in the canvas API specification saying that text rendering is not supported because it would be difficult to handle variations in font sizes across platforms. This is odd as the desktop APIs manage this with a function to get the dimensions of a particular string in a particular font, and developers have been using such functions to great effect for decades. I think the real reason for the deficiency was simply that they (the Safari developers) did not need text on their canvasses, and so were not in a position to spend time implementing it.

This makes it pretty clear that for the majority of cases there is only one viable choice, and it is a great choice. SVG takes all the advantages of HTML, seperating content and style and logic, and applies them to graphics in a way that works just as well in a standalone viewer as it does embedded in a web page. There are aleady tools for working with SVG, most first rate vector drawing packages can at least export to it. The standard really has been around for a while, and it is good to see browsers support it. Of course there is one fly in the ointment, Internet Explorer is still dragging its heels and remains the bane of all web developers and web based development. The internet is supposed to be able to route around damage, given a little time, so maybe there is hope yet.