September 12, 2001
Last week, the World Wide Web Consortium issued Scalable Vector Graphics (SVG) 1.0 as a Recommendation. SVG, as its name implies, is an XML application for describing two-dimensional graphics in the form of vector-based objects. As well as allowing normal 2D drawings, SVG is scriptable, enabling user interaction, and it incorporates animation capabilities from SMIL.
Along with W3C XML Schema, SVG is one of the most important technologies to emerge from the W3C this year. It's certainly been long in the making -- SVG's first public Working Draft was published over two and a half years ago. Although many have been impatient for the final recommendation, this lengthy period of maturation has produced benefits in terms of the quality of SVG's specification and the number of supporting implementations.
It's No Banana
The text of the SVG Recommendation makes for an impressive read. It starts with a useful Concepts section that explains the key points and motivations behind SVG. The specification itself is beautifully formatted, comprehensively hyperlinked, and filled with examples. In addition, it is also very well indexed and useful as a reference, both for SVG processor implementers and those wishing to create SVG diagrams in XML.
Accompanying the recommendation is a test suite, allowing developers of SVG implementations to verify their code against the expected renderings of SVG documents. Although W3C XML Schema has recently gained a test suite after going to recommendation status, to have one available through the development of a specification and at publication of the recommendation is an excellent move. It has also enabled the W3C to publish implementation conformance information for the various available SVG renderers.
Another encouraging feature of SVG is that it has had significant implementation experience during its development, which appears to have been highly beneficial to the Working Group. This has resulted in a commercial vendor, Adobe, with software support for the specification already in its third public release cycle.
Breaking Out All Over
Setting aside the excellence of the specification itself, we must ask where SVG will succeed. After all, the best of technologies have been known to fail due to poor adoption.
On the Web, SVG's most immediate competitor is Flash, the only real established technology for vector-based illustration and animation. Microsoft's Internet Explorer has had support for its own predecessor to SVG, VML, for a while now, but this hasn't really achieved widespread deployment on web sites. It is clearly the W3C's hope that SVG will supplant Macromedia's Flash to a certain extent, bringing as it does the benefits of integration with the emerging XML infrastructure both in browsers and on the server side, and of course the open process of a W3C-fostered specification.
There are two obvious obstacles to this happening: browser support and authoring tools. Microsoft has just shipped IE6, which doesn't have SVG support (see Microsoft's Internet Explorer 6 and Standards). It will take at least a year before IE6 gets as strong a hold as IE5 currently does. So if even if IE6.5 or IE7 includes SVG, it looks like it will be a long time before SVG will be able to be taken for granted on PC browsers. The Mozilla browser is likely to have SVG support at some point in its development, but the prospects for Mozilla being a source of widespread SVG compatibility look worse than waiting for Internet Explorer, at least on Windows platforms. For now, SVG on the Web will have to rely on browser plugins. Adobe's plugin, while a wonderful development, weighs in at a hefty 3MB or so download. All told, the browser situation doesn't look that great.
(If you don't think the battle on the Web is Flash against SVG, take another look. Despite Macromedia having a representative on the SVG Working Group, it has absolutely no reference to SVG on its web site, and it's just completed a deal with Microsoft to ship the Flash player as part of Windows XP. For its part, Adobe is partnering with RealNetworks to get its plugin distributed.)
Although there are some emerging authoring tools for SVG, there's quite a way to go to catch up with the place Flash has in the web designer's toolkit. The situation seems a bit healthier than for browsers though, as Adobe's offerings for SVG authoring get a head-start by piggy-backing on their existing web design and authoring tools.
However, I don't believe that SVG's initial victories will be on the traditional PC browser-based web. SVG presents too few advantages over existing technology to immediately supplant it. The scalability of the graphics buys little on the personal computer screen, where low resolution is the order of the day. If, however, you consider alternative devices, there is a whole spectrum of opportunity for SVG.
Also in <taglines/>
The Web is increasingly no longer limited to the traditional PC. There's a significant emerging constituency of devices with limited display size: PDAs and cell phones. Few of these devices have similar specifications, and there's a need for display technology that allows the designer control, yet enables them to create an interface suited to the viewing device. SVG, especially with its integration with Cascading Style Sheets (CSS), is ideally suited to exist in this niche.
At the other end of the scale, we see the Web used increasingly for the distribution of technical documentation. Material, such as engineering drawings, needs to be reproduced to the highest fidelity, both on-screen and in print. SVG, which, unlike bitmaps, does not degrade at high resolution, is ideally suited to this application.
As display technology continues to improve, it is likely that quite a number of users will be staring at 200 to 300dpi monitors in a few years' time, creating new opportunities for graphics formats such as SVG that adapt well to different resolutions while keeping file size low.
So, although getting anything not blessed by Internet Explorer into widespread use seems difficult, the growing diversity in browsing devices provides opportunities for technologies like SVG to shine.
All Mixed Up
As readers of this site are no doubt aware, the simple fact that SVG is expressed as an XML application brings it strong benefits, and in turn enables other XML applications to enjoy its functionality. Like any well-dressed W3C technology, SVG has its own namespace. This means that, at least in theory and hopefully soon in practice, SVG can be inserted inline into XHTML documents (for a demonstration of this, check out the X-Smiles browser). XSL Formatting Object processors, such as Apache FOP, already support the use of SVG in order to provide graphic capabilties inside documents formatted for print.
The Working Groups developing SVG and SMIL (Synchronized Multimedia Integration Language) have both espoused subsetting as a way of developing their specifications. Recognizing that not all of the features of a technology may be needed or implementable in certain settings, future specifications will support well-defined subsets. This will, for instance, allow cellphone manufacturers to support exactly the same flavor of reduced-functionality SVG.
And it needn't stop there. There's no reason that if you're developing an application that needs a way to express, say, rectangles, you shouldn't just bring in SVG. We now have an interoperable XML vocabulary for talking about figures in two dimensions.
As an addition to the family of web technologies, SVG is a welcome arrival.It emerges at a time of new opportunity and challenge, as new devices and user communities proliferate. The W3C SVG Working Group has done a fantastic job with the development of the specification, and it's set high standards that other groups would do well to aim for.