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.

• This finally allows for true MVC (Model-View-Controller) GUI design practices, making elements at all levels more modular, reusable, evolvable, dynamic and easier to maintain.
• Interfaces can be highly dynamic and responsive to the environment. The same codebase can define programs that change language on the fly and change styles, sizes, and widgets as needed depending on the runtime environment (if the application is running within an embedded device (PDA, cellphone) or browser, or if the display is a digital camera LCD, high-definition television, or movie theater screen).
• Applications can easily be made accessible, usable by a wide variety of people including the blind, hearing-impaired, and users of text-only interfaces.
• Applications can be dynamically translatable for foreigners and easily repurposed into other formats.
• Applications are suited for rapid, collaborative programming and workflow, allowing team leaders, designers, and programmers to work in remote, distributed groups easier. Design prototypes can be made long before application logic is coded, in any tool that can export to PDF or vanilla PostScript, and vice versa. Once approved, existing interface designs can be quickly incorporated into production systems with minimal impact.

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.

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:

• The ability to turn off text selectability/event listening or otherwise lock the same globally, perhaps via a "selectable" or "listenable" attribute. SVG GUIs must be able to "lock" the screen during window dialogs and mouse dragging operations such as with scrollbar widgets or window dragging, and nothing can be allowed to intercept mouse or keyboard events during certain operations. Without this capability it is cumbersome to develop GUIs that contain rich widgets that meet the expectation level of everyday computer users.
• The ability to have a "zindex" or "layerorder" attribute so that the presentation order of overlapping objects can be specified and dynamically changed. This alone can make for very efficient code when programming certain types of applications that require overlapping objects, such as "Stickies", multi-page documents, and window managers. It is not clear how the CSS z-layer property works with SVG.
• Stylable flowing text as mentioned in the SVG 1.2 working draft of May 10, 2004.
• The ability to dynamically generate a bitmap from an SVG region. This would allow the efficient coding of virtual windowing systems, remote display applications, mapping applications, and other applications that need to generate thumbnails and icons.
• An arc tag, or attributes that allow one to specify beginning and ending degrees of arc, as mentioned by Kurt Cagle.
• The ability to get the color value at a particular point.

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

• Thanks to the Web, developers have come to expect the ability to create designs that dynamically respond to display size and other factors, via tables, percentage-based values, and the nature of browsers themselves.
• Such a capability allows for more efficient code, rapid development, and flexible GUIs.
• Traditional application developers typically use layout managers and other tools that allow for dynamic layout (as in Java's Swing toolkit). People will not make interfaces in SVG if they continually have to specify fixed coordinates or write layout managers in JavaScript.
• One must be able to make use of overall client/canvas dimensions, and perhaps other layout-related values, within expressions.
• One of the touted benefits of Laszlo is its ability to use such expressions along with its built-in layout managers. As it has been explicitly tailored to suit the needs of application developers, the SVG authors would do well to examine the language.
• One can also refer to the CSVG effort at Monash University.

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:

• Work with Apple to provide technology so their new Dashboard widgets can be made in SVG. DHTML is so yesterday; consider what DHTML developers today have had to do just to make rectangles with rounded corners. Not to mention brushed metal textures.
• Implement native Quartz calls so their Mac plug-in is super fast. As far as I know, they're using the same code for drop shadows in MacOSX as they do for SVG, and Photoshop, for that matter!
• Enforce ASV plug-in updates and installation every time Adobe Reader/Acrobat is installed or updated.
• Put an automatic updater in their plug-in.
• Ensure that browser "search for a plug-in to handle this content" pages point to the plug-in so that installation can be done in as automated a fashion as possible.

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.