SVG Notes
October 2004
By Kevin Hughes,
SVG Is The Future

Ever since I started making Web pages in 1993 I've used two programs in developing graphics for every site I've ever made: Adobe Photoshop and Adobe Illustrator. As a designer, those were the tools I knew and cared about, and the ones that allowed me maximum graphic expression when Web technology fell short. Over the years core Web technology has gained more graphic flexibility while Adobe has reshaped its tools to accommodate. So far, so good.

But the overall trend in Web development has always been for the Web to turn into a multipurpose application platform, from day one. Why? Because of its responsiveness to the environment and its inherent interactivity. Even the proto-browsers, Pei Wei's Viola and his earlier efforts, included scripting, with great influence coming from HyperCard. Even without client-side scripting, the Web introduced the ability to make dynamically resizable media in a way that was trivial to create. This ability, which was not even in HyperCard, was at the time only available to custom standalone applications with layout management code. And the ability to easily create links to various media types led developers down a long path: the need to control the presentation of linked media, the need to receive input, the need to display multiple languages, the need to get information from the runtime environment, the need for dynamic content, and finally the need for client-side logic. Sounds a lot like what a traditional standalone application does.

The second overall trend was that of modularizing media into separate functional areas: Photoshop and Illustrator eventually added layers and filters; CSS helped separate presentation from content. This practice had already been used in application development by Apple, with its separation of application resource and data areas. Today most Web developers use CSS for presentation, (X)HTML for content, and ECMAScript in some variant for logic. There are many other functional areas, such as relationships (robust linking, versioning, mirroring, backups) and metadata (ala "the semantic web") which are all being worked on and which hopefully will one day be taken for granted by developers as necessary parts of any application.

Today there are more Web pages than software applications that have ever been written. Every page is a tiny application in itself running on the browser operating system. SVG is a huge leap forward in Web development in that it cleanly separates rich design and style elements from logic, allowing designers and programmers to use the tools they are familiar with, to the fullest extent possible.

The fact that the design language is XML, validatable, easily parsable, vector-based and resolution-independent is nice. This means easy integration into all manner of design projects and workflows that output to physical media (such as paper). It means the ability to create high-quality platform-independent multilingual forms that can be run as standalone applications or Web pages, filled out, printed (with the ability to dynamically adjust layout depending on printer qualities), and processed in batch automatically for database entry, all within the same file and codebase. Of course, the same goes for any SVG application, whether it be a multimedia presentation, spreadsheet program, or travel brochure. With SVG, there is no longer a line between "application" and "graphic" - everything is dynamic media.

The real exciting thing, however, is the ability for the control logic to be swapped out for more flexible dynamic languages as needed. As SVG and SVG-like languages such as Laszlo gain popularity, people will clamor for more extensible languages than JavaScript that can go beyond the client-only sandbox. Perhaps a variant of JavaScript will have to be made that can deal with the filesystem, network, operating system and other external resources. But wouldn't it be more appropriate to create SVG applications using PHP, Python, or other more full-featured languages? Dynamic languages have been (as in the case of Smalltalk) and will be the future. As computers get faster it is inevitable that the common programming paradigm become more high-level and processing power moved towards the client side. SVG falls neatly into this evolution.

What's Needed

More progress towards the development of high-quality, fully standards-compliant SVG engines is needed. Today most engines are quite slow, and the Adobe SVG Viewer (ASV) could stand to be an order of magnitude faster if not more. There are a number of small gripes concerning ASV, but as development continues these should go away.

More effort on the part of browser developers is needed. SVG plug-in and native SVG support must be continued, with an emphasis on making SVG-to-HTML and HTML-to-SVG communications work in a consistent manner first (mouse/keyboard events and function calls), and second on implementing as much of the SVG 1.1 specification as possible. I put more emphasis on SVG/HTML communications because much useful rich client development can be done immediately even with an incomplete engine if browser integration is worked out.

Lesser features it would be nice to have in SVG:

But for (Web) application developers the most important thing is expression-based attribute values, mentioned in an earlier working draft.

There is also a need to be able to connect to external data sources. The ability to simply save preferences to a cookie would be a boon to application developers. I would be careful about putting overly complicated features along these lines in SVG, as it can be argued that it is not an appropriate feature for a graphics/interface design language. It may be better to put this capability in JavaScript/ECMAScript and work on standardizing HTML JavaScript to SVG communications instead.


There's little that Flash can do that SVG can't do, granted that extra multimedia capabilities are in the latest SVG working draft. The only significant differences are in engine speed, browser support, and implementation consistency (not necessarily popularity). So what can be done to help speed up the adoption of SVG?

The ball is in Adobe's court. The Illustrator SVG capabilities are excellent, but they need to show that they continue to support SVG by updating their viewer and SVG Web site and demonstration apps in a timely manner. In addition, they could:

Also, note that there is nothing that prevents someone from writing a dynamic Laszlo (LZX) to SVG convertor in PHP, aside from plug-in speed and SWF conversion.

If there isn't one already, it would be nice to see a site track the various implementation/compatibility levels and quirks of various SVG engines, like quirksmode.

Looking ahead, there could stand to be efforts for making today's dynamic languages ready for real GUI application development using SVG. This mostly means adding support for multithreading, Unicode, and internationalization. Once these things are well baked into PHP or other dynamic language, there is no stopping the new application development paradigm. With PHP support you'd convert hordes of developers immediately. Applications could run on the Web and be deployed on the desktop with the same code, and could be created and edited by just about anybody, if you wanted them to. Every application could print in full PDF quality. Sounds a bit like the promise of HyperCard, but with vector graphics...

With SVG we are now at the edge of a new shift in how people think about applications, just as we were when the Web first started. We've had a long enough fight trying to get our content out of proprietary data jail formats, and sure, we have a ways to go - but every HTML page I wrote in 1993 still renders the same in modern browsers on modern computers on every major platform; with how many programs can you say that? Let's try to do the same for applications and help make them more future-proof with SVG.