November 17, 2009, 2:50 PM — SVG is hot.
That is, I like SVG: it's a graphical format that goes a long way toward achieving visual effects that I want my applications to have, and I believe it's ready to "infect" the general population of Web developers any week now.
Duelling visualizations
"Visual effects" for me generally are "data-based"; I do a lot more with reports and analyses than games or art. Restriction to this dry domain still finds plenty of eye-catching work. The New York Times recently featured
unemployment charts that interact (in a limited if stylish way) with the reader. This, like many other outstanding visualizations on the Web, is delivered as a Flash movie.
Even static images, like this related one 
from FlowingData, are rarely seen as SVG; the author worked in SVG for reasons he explains, then, without explanation, published as PNG.
It's easy to guess his reason: Internet Explorer (IE) doesn't support SVG.
I'm in the happy position where most of the end-users of my Web applications are professionals and technical workers, and I can reasonably require that they use a modern version of Firefox, Safari, Opera, or one of the many other browsers that support SVG. Why is that such a good thing? Advantages of SVG have been well-known for many years: it's an open standard, instances are XML, images are scalable, instances often can be compressed smaller than corresponding JPEG, and so on. FlowingData rightly emphasizes its scriptability: in contrast to raster-based formats like GIF, JPEG, and PNG, it's a simple matter to issue commands like, "lighten the red in the upper left", or "highlight the second floor in yellow". That simplifies the visualizations FlowingData produces; rather than having to trace out the pixels that represent, say, "Michigan", or "the delivery zone", these concepts can simply be passed around programmatically by corresponding IDs. You can see the appeal to developers.
Moreover, "data as service" is starting to take off, putting a premium on flexible tools that encourage us to script together several distinct data- and visualization-feeds. Data mashups are going to be big.
Finally, delivery as SVG has one overwhelming advantage over raster-based graphics and even Flash that the compatibility battle with IE has obscured: all of SVG's scriptability is accessible through supported browsers! To make a GIF "live", for example, you must define a separate "map" file which relates pixels to actions; while this has taken us a long way, it's also led to whole generations of Web applications which were hard to maintain and erratic to use. SVG is a higher-level format, though, where it's natural to express, "if I move the mouse pointer into the interior of the combustion chamber, then pop-up a chart which shows ..." SVG images can complement and support textual reports which flow around them in a Web-based display, and, with the right scripting, the text and the picture can interact right before end-users' eyes, without having to return to the server.
These client-side capabilities have been implicit in SVG definitions and implementations for several years. They've also been incompletely documented. I plan to publish a couple of tutorials on the subject this winter, and look forward to a wealth of exciting new applications that will take advantage of client-side graphics scripting.
Conclusion
Later this week, I'll describe other uses of SVG, along with a few more general comments on the state of Web programming.
