Appendix B. Scalable Vector Graphics (SVG)

Our work with XML uses the language to encode fairly abstract data like quiz questions or player identities. We use Flash to convert these into on-screen displays. Typography, layout and illustration ”as well as animation and interaction ”are employed to create a display that beautifies the data and hopefully clarifies its meaning.

There is a huge divide between the XML data and the graphics used to display it. The graph ics are transmitted as .swf files in Flash's proprietary encoding. The graphic data exist in a different address space not directly accessible to the functions that manipulate the XML data.

This divide may disappear. A very well-supported effort is underway to create an XML vocabulary for web graphics. The aim of this effort is universal browser support of a nonproprietary, highly sophisticated graphic language that meshes cleanly with the other technologies of the web.

Vector graphics, typography, and scripting are valued by this consortium. The standard that resulted from their efforts is called Scalable Vector Graphics (SVG). Its functionality overlaps the SWF functionality ”it has a set of graphic primitives that are similar ”but is somewhat more sophisticated.

The graphic primitives include the shapes of swf plus rectangles, circles, and more sophisticated bezier curves. The fill effects are like those of Flash, including outlines, gradients, masking, pattern fills, and transparency (all animatable), and also include plugin functionality similar to Photoshop filters, which can be applied to lines as well as fills.

SVG attaches font characteristics to true text: Rather than being buried in an swf file, pure text is exposed to search engines and indexing robots while retaining all the flexible styling ability that a Flash file would have.

All the tools of an interactive page can be integrated seamlessly into an SVG graphic: JavaScript, DHTML, XHTML, and CSS. The elements of a graphic can be distributed across many files or across many web sites, allowing great efficiencies of maintenance and flexibility of presentation to those who plan their site well.

Surprisingly, despite the fact that these graphics are presented in plain text XML, the early tests show files that are somewhat smaller than the matching SWF files (possibly because they were hand-encoded?). However, automatic zip compression will be introduced to the web at the same time as SVG. The text of SVG compresses easily, and the standard seems far more efficient than swf.

The future SVG-enabled browser (IE 6.0?) will be the equivalent of today's browsers with Flash player plugins. There are some important differences to look forward to. First, the SVG player will not be a proprietary system but will have support from multiple vendors. This is good and bad. Multiple vendors will compete for high-performance, highly compliant implementations , and that tends to result in better products brought rapidly to market.

On the other hand, veteran web developers will recognize the pain in store for them. In the past, we have had to straddle (for example) the slightly different renderings of HTML, Java, and scripting languages of Netscape, AOL, and Microsoft. The dream of a page rendering identically on different platforms will always be a dream. Maybe if we are lucky, it will display correctly on multiple platforms.

But the significance of SVG is greater than second-sourcing a player plugin. It is useful to have the graphics and script exposed in the transparent coding of XML. Transparent source code raises issues of site and transactional security. And it challenges (as most web protocols do) the competitive instinct to treat source code as a trade secret. Yet it opens up a new world of tremendously dynamic web entities that will make today's Flash sites seem stiff and unresponsive . And it invites the creation of a multiplicity of tools and libraries that push the envelope creatively, technically, and in fulfilling the needs of niche communities.

Even more significant than the transparency of the XML code is the integration of scripting, graphics, HTML, and XML into a single Document Object Model, at the core of the browser. An ActionScript programmer now cannot do something as simple as read an XML file containing (for example) sales data and create a simple area chart from it. While the XML data is accessible, the points in a polygon are not.

In an SVG environment, this code would be trivially simple. In fact, since the incoming sales information and the displayable SVG graph are both legitimate XML codings, the graphing function could exist in as simple a form as an XLS transformation file. Today a stock-charting site delivers dumb gif files. In the future it might combine XML-based data, a charting rubric ( expressed in XLS and rendered in SVG) within a publisher's presentation coded in some kind of HTML. Each of these files is simple and independent. Each can be provided by a different supplier, allowing a web of flexible relationships and profound personalization.

When (and if) SVG will become ubiquitous is unknown, but momentum seems to be building. Macromedia has expressed support for the standard. IBM, Corel, and Adobe have been even more enthusiastic. Recent advances in Flash, starting with ECMA coding and XML readiness in version 5.0, can be seen as steps in the direction of this emergent standard. Hopefully the paths of Flash and SVG will continue to converge and the skills we are developing in ActionScript code and in XML will serve us well in the future.