HTML, invented in the paleolithic predawn of ARPAnet, when computer users marveled at green phosphors flickering on dumb terminals, was an advanced technology for its day. But hardly anyone considers it the e-doc format of the future. Whatever its other virtues, HTML’s failings in areas like extensibility, metastructure, and graphics have become too painful to ignore. Something much better will be needed to carry the Web forward into the 21st century. And fortunately, something better is on the way. It’s called Scalable Vector Graphics.
More than two years in the works, Scalable Vector Graphics (see the draft standard at SVG at W3C) represents a collaborative effort by some of the biggest shakers in the computer world to find a workable cross-platform solution to Web imaging.
Among the firms represented on W3C’s SVG committee are such tiny, inconsequential lightweights as IBM, Microsoft, Apple, Xerox, Sun Microsystems, Hewlett-Packard, Netscape, Corel, Adobe, Quark, and Macromedia. Most have committed publicly to supporting SVG in future products. A few, such as IBM and Corel, have already begun distributing public betas of viewing and/or authoring apps.
When native SVG support arrives in browsers (as both browser makers have indicated will happen soon), the Web will undergo a facelift the likes of which haven’t been seen since the Gabor sisters arrived in Hollywood. Web pages will begin to look a lot more like magazine pages, with DTP-inspired typographic effects and pixel-perfect positioning of page elements. Pages will be custom-zoomable, and antialiasing will make every element look crisp at every magnification.
But easier-to-read pages are just the beginning. Pages will also be fast-to-download, because text (for once) will be gzip-compressed, and some of the most elaborate art and animation effects will be vector art, which has the potential to be much smaller than bitmapped art.
If you’re getting the idea that SVG is mainly just a graphics engine for drawing stroked/filled graphics of the Adobe Illustrator variery, think again. SVG is actually a CSS-compliant, Unicode-ready XML grammar for encoding text and/or graphics (see the Document Type Definition at http://www.w3.org/Graphics/SVG/SVG-19990812.dtd). That means you can embed SVG files inside HTML or XML, using the <embed> tag, or you can use SVG as a standalone document type. (Browsers will be able to deal with it either way.)
Also, within SVG files, you can embed inline graphics of the JPEG or PNG (Portable Network Graphics) variety, using the <image> tag. So you’re by no means limited to stroked/filled vector art.
And of course, you can style your text or your graphics with Cascading Style Sheets (which in turn can be embedded, called inline, or externally linked).
All of which, taken in its totality, makes SVG a very flexible and powerful document standard indeed.
But wait! You haven’t heard the best part. Are you ready for … scriptable animation?
Like any good Webdoc standard these days, SVG follows a Document Object Model. And in fact it’s the same model that version-4.0 browsers everywhere already follow with HTML. Which means you can use JavaScript to access and manipulate SVG page components at runtime.
Think for a moment about what this really means. Every style property (fill color, stroke width, opacity, etc.) for every art or text element on an SVG page can be manipulated using JavaScript. Every x-y position attribute for every element can be manipulated; hence, objects can be moved, or animated. Even the raw transform matrices for objects (here, wer’e talking about the things that make scaling, rotation, and shearing happen) can be tweaked on an object-by-object basis at runtime.
And since the event model is the same as for HTML pages (using, for example, “onmouseover” and “onclick” type events), it means objects can actually be made to move across the screen in response to the user’s mouse actions.
If you’re reading between the lines here, you’re probably getting the distinct impression that SVG puts a powerful graphics authoring capability directly in the hands of the JavaScript programmer, for the first time ever. And you’re 100% correct.
SVG will mean a revolution in Web animation. It not only lets JavaScripters do flipbook-style animations, but invites whole new kinds of “morph” animations based on continuous ramping of opacities, stroke widths, character widths (for text), fill color gradients, curve radiuses, and whatever else can be animated in SVG. Which is to say, most everything.
By now, you’re probably wondering where you can get your hands on a real, working SVG viewer and some example files to play with. You’re probably also wondering how in the world a person creates SVG files. Let’s answer the first question first.
If you’re a Windows user, you can get a free SVG viewer application (and sample SVG files) from IBM’s Alphaware site. A Java-based viewer is also available free from CSIRO in Australia (source code is there, too, in case you want to try porting the viewer to another platform).
Mac users are out of luck at the moment, since none of the SVG players has announced a public beta of Mac-compatible SVG viewing software yet. Private betas of SVG plug-ins for both major browsers have, however, been undergoing tests for six months. (As a tester of the Netscape viewing plug-in for MacOS, I can tell you from first-hand experience, these plug-ins rock!)
In terms of SVG authoring software, Corel has made available a public beta of its SVG export plug-in for CorelDRAW 9 users. Adobe is known to be beta-testing a similar plug-in for Illustrator 8.01, but the plug-in is not publicly available (yet).
Strictly speaking, you don’t need anybody’s fancy SVG authoring software to create SVG docs, because any ordinary text editor will do. The same tools you’ve been using for hand-crafting your own HTML will do fine for hand-crafting SVG.
And don’t let anybody tell you that you can’t roll your own SVG from scratch. I’m here to tell you it’s not only possible, but well within the native authoring ability of anybody who is comfortable with HTML. In some ways, writing SVG is actually much more intuitive (and certainly more rewarding visually) than writing HTML. In Part 2 of this article, which will appear next week, I hope to prove it to you, by showing you how to write some simple SVG files using nothing more than an ASCII editor.
Until then, have a look at W3C’s SVG page along with the resources at SVG Central. And remember, Something Very Good lies just ahead.
This article first appeared on WebDeveloper.com in November 1999. It was written by Kas Tomas.