| SCALABLE VECTOR GRAPHICS (SVG) |
| SVG: FLASHIER THAN FLASH? |
svg: is it flashier than flash?
on may 13, 1999, i sat in a seriously-toned www8 conference room with about 100 developers, standards makers, and various other hard-core web heads, listening to the w3c's chris lilley deliver a public progress report on the status of svg (that's "scalable vector graphics," an xml-based markup language for describing vector graphics). as chris progressed through the subjects of his talk, my mind wandered a bit. i thought "gee, it's about time the web got native vectors..." (pondering the thousands of mercilessly flat .gifs for which i am accountable) and then "i guess it'll be over a year before a generation of browsers that understands svg will be prevalent enough to offer a worthwhile svg audience" and then "i wonder when flash will start exporting to svg". and then i was interrupted.
by what?
a fish.
chris had opened an svg graphic of a fish (well a whole underwater scene actually) in an svg activex control running in ie5. (the w3c's experimental browser/editor, Amaya, also already supports a precursor to svg). after the image was finished displaying, chris resized (dare i risk "scaled"?) his browser window, which resized the image of the fish, which caused gasps throughout the (techie) audience, which interrupted my mental wanderings. (okay so it was really the resizing of the fish--not the fish itself--that interrupted me).
the gasps caught my attention because i thought everyone had already seen dynamically sizing vector graphics in a browser via macromedia's flash plugin. apparently not. or so i thought. somewhere around this point, chris interjected a funny anecdote: when he gives his svg demo to techies, they always ask "what's a bezier?" and when he gives it to graphics experts, they always ask "what's a tag?". so, since he was addressing an audience full of techies, chris bent a steel ruler and said "that's a bezier". chris's distinction between the two audiences' understanding of one technology came at the exact same point i was trying to figure out how the crowd--which was full of people who work on the standards of the web--could have apparently missed seeing flash websites.
my answer came later in the week during an informal chat i had with chris in the "computer room" (a curtained off space throbbing with ethernet connections and telnet clients where conference attendees could go between sessions for their fix of streaming data). i was keen to learn as much as i could about how and when svg will actually work.
"is svg scriptable?" i asked.
why *does* it have to be in a browser? ask yourself that one again. if your answer was anything like mine--"because that's how everyone gets to shared global data these days"--then you're soon going to understand why many of the audience, full of standards developers, gasped at a vector fish resizing in a browser. you see, up until chris's talk, i had been thinking of svg as just another graphics format. specifically, i thought of it as a w3c endorsed vector graphics format for web display. the only differences i could see between svg and macromedia flash's .swf format were 1) feature set (flash has lots of things like sound and interactivity which aren't built into svg), 2) text (svg) vs binary (swf) encoding, and 3) w3c support (while swf is an open format now, it is still controlled, and can be updated arbitrarily, by a single vendor). from that point of view, i was surprised to think that not all the people sitting in an svg lecture hall had visited samples of what appeared to be the strongest competition: swf. what i had not yet understood was: 1) unlike swf, svg is built from the ground-up to exist in a wider world web than the world wide web, and 2) svg is not a graphics format alone in the world--it belongs to the family of xml.
"of course, it complies with the dom." replied chris.
"so is that how it will animate? via javascript? aren't you a bit worried about the instability and combatibility problems with javascript?"
"not necessarily. after all svg *is* xml, so it could easily work with smil [synchronized multimedia integration language] for timing and interactivity. smil already provides a way of describing those things in xml. and we know there have been problems with ecmascript in the past."
"it's too bad we'll have to wait so long before we see this in a browser, considering IE5 just shipped...it might be over a year before people have 6," i commented.
"why does it have to be in a browser?" asked chris.
chris's rhetorical question ("why does it have to be in a browser?") made the breadth of the svg project much clearer to me. svg is a generalized language that can be used both by computers and humans to describe vectors. an obvious application of svg is the display of graphics within a web browser, and to that extent svg (in combination with css, the dom, and ecmascript) is similar to flash. but there are many more possible svg applications. consider these examples: 1) any graphics program (illustrator, freehand, coreldraw) can have an export module for writing out svg files. svg could be a universal language for transferring files between vector based applications. 2) because a good xml parser can be had for free, most apps could quite easily have an svg interpreter added to them. this means that data held in svg format could, with a manageable amount of effort, be accessible to nearly any software or hardware, from office apps like excel and word to hand held devices, like palm tops and cell phones. so one day you might create a graphic in word, email it to your friend, who reads the text description of it on her cell phone, and then posts it on her website for her colleagues to view--one of which reads it into illustrator and continues working on it where you left off.
the universality of these examples and of svg itself stems from svg being an xml application. xml is the generic syntax svg uses to form a vocabulary that describes vectors. but svg is only one of the many types of data that are described with xml. xml also provides the generic syntax for describing math (mathml), multimedia (smil), and multitudes of text-based data types like product catalogs, pharmaceutical specifications, and web pages. in theory, xml could be used to describe any type of data (that's where the "x" for "eXtensible" comes in). so, because it is written in xml, svg has enormous potential for interoperability with other data types, and for rendering via multiple output environments. as chris said, many of the basic capacities for time based events are already offered in the xml based smil, so svg could naturally be combined with smil to provide animation capabilities. and once support for xml in general and svg specifically begins to spread, a single svg file could very reasonably be expected to perform equally well on a printer and a web browser, and will be able to offer alternative content for everything else--from braille screen readers to pagers.
suddenly tim berners-lee's discussion of data independence during his opening plenary for www8 made a whole lot of sense--the data, be it text or vectors, should not be tied to hardware *or* software platforms (browsers included). the creators of svg are striving towards more than a vector format for the web. they are striving for a vector format that is *also* for the web. which is perhaps why a collective gasp arose when chris showed the fish in his talk at the www8 conference. the fish didn't show that vector graphics could be done in a web browser (heck future splash, now flash, did that years ago). the fish showed that the w3c's work on a generic xml vector graphics standard was mature enough to have a real world implementation. that implementation just happened to be running in one of the most pervasive modes of data sharing around today. the web browser.
so how does svg compare with flash? well, flash does a bunch of things that svg working group hasn't fully worked out yet (like fonts, animation, and interactivity), or can't accomodate for alone (like sounds). but these things are really outside of the native scope of svg. svg simply provides a means of describing vectors while allowing for extension through other xml-based languages, scripting languages, css, and the dom. that said, svg does provide some unique features that flash could truly benefit from: things like live client-side text, alternate content, and multiple style sheets. but svg's real promise is its interoperability, which will allow it to be used for a vast range of purposes (from data storage to onscreen rendering and print rendering). the .swf format, on the other hand, currently plays a much different role: it's a (primarily) web-based multimedia format, not just a vector format.
even so, the question has to be asked: what effect will svg have on flash's .swf? will it work with it? will it wipe it out? we're all going to have to wait quite a while to find out...but theoretically anyway, the .swf format *could* eventually be replaced by a collection of modular media standards bound together with the shared structure provided by xml. and one of those "modular media standards" would be svg. but a lot of standards work will have to be done before that can even start to happen, and once it does, a lot of time will pass while the various technologies are deployed world wide. still, macromedia can definitely see the potential of svg and xml. they made that clear when they lauched flash 4 by briefly making a move to re-brand .swf as a "hybrid media type" called active vector media. the original article on macromedia's site (which was revised twice and then quietly removed) actually felt a trifle more adversarial than i would have thought necessary, because whatever happens to the formats, one thing is clear: the flash, director, dreamweaver, and freehand teams at macromedia have spent years working out how to handle the authoring side of things, which is an enormous part of the media equation. whatever the exported media type(s), those tools are already more than ready to provide developers and designers with a sophisticated authoring environment.
in the midst of all the speculation and positioning, chris lilley and the w3c gang are zipping right along, hoping that svg will reach the "proposed recommendation" stage by august 1999. expect 6-8 weeks for approval of the final svg spec thereafter. then we'll all have to use svg plugins (adobe already has one in the works) to view svg while we wait for the first generation of svg capable browsers to be released. but at least we'll have quake III around to keep us busy while we wait. :)