Documentation and imagination crucial to SVG

SVG technology is in place; now it's time to use it.

While most chatter about SVG and related HTML5 standards focuses on "browser demographics" of the "will Webkit-based mobile units compensate for the long end-of-life of IE5-8?" sort, we've passed the "critical mass" of rendering browsers, I claim. Now what SVG most needs is documentation of and familiarity with the capabilities that are already present. The last few important steps for SVG happened when important browsers expanded their SVG coverage; the next few important steps will happen when creative people catch on to the striking two-dimensional visual effects SVG enables.

To that end, this short article will illustrate how SVG not only is feasible in an abstract sense, but is compatible enough with other patterns to "in-line" readily in the ITworld blog system. That's a significant qualification: if I told you you could create fantastic multimedia extravaganzas, but only if you coded in PL/I, and displayed them on an Amiga ... well, those are the kinds of things that discourage adoption. SVG is relatively conventional-looking XML, though, and "plays nicely" enough with existing systems to make the examples below more-or-less visible (unless you're using Internet Explorer before version 9)--and I entered them without crashing the blog editor!

Peter Thompson, for example, has written this animated



UML diagram to model the "Observer Pattern". While it doesn't fully work in all browsers (Opera probably makes it look best, for now), and certainly isn't as attractive as when shown at full size on its home server, it nicely hints at the possibilities for "live" thumbnails, ones that scale nicely, but retain their dynamic and even interactive character. Blogs can be a lot more than just words white background!

Even easier to render is a "free-running" animation like David Dailey's floral ovals, taken from his "Rotarium". Yes, GIFs can also be animated--but do you know how to express and maintain a GIF animation in only 38 lines of human-readable source?

A final example for today: Jake B demonstrates in his "Yet Another JavaScript Blog" last year that, in an extreme case, SVG content such as a Venn diagram of his activities



can even be "in-lined" as XML data, to maximize portability across existing browsers. While he calls it "evil" and a "terrible hack", I've frequently and shamelessly used the technique, often because of limitations on the server side. What do we mean by this 'URL-encoding'? In this case, the source for this page looks something like

        ...
    <object data="data:image/svg+xml,%3C%3Fxml%20version...
              [scores of lines more of pure-ASCII data]
            "></object>
        ...

Jake B even supplies a Rhino script for automation of the inlining. Jake B also thoughtfully shows examples of less radical, if sometimes less portable, means to the same end of inclusion of SVG in HTML, by using HTML and XHTML syntax, respectively, for compound documents.

Summary

The point now is not what amazing things SVG can do, given enough effort, however much that story deserves to be told; more compelling for me, though, is the wealth of effects that are simple enough to begin to use today. Even blogs aimed at mobile audiences, which reverted not just to text, but sometimes to rather reduced alphabets, can enjoy the visual sizzle of SVG. It's ready to go.

And do you see what's just over the horizon? UML and other software-engineering diagrams can be built and animated entirely automatically, from XMI by way of XSLT, for instance, then edited visually, and inverted, again with XSLT. Such a round-trip tool could be not only purely client-side, but browser-free; it's easy to imagine Eclipse, for example, acquiring a platoon of fast code-visualization tools based on SVG.