The W3C launched the Scalable Vector Graphics Working Group in 1998 to provide the vector graphics counterpart to HTML. The SVG WG chose to adopt all of the same general approaches as HTML (markup, DOM, scripting, styling) but replaced HTMLs
,
and elements with vector graphics element such as , and . With various events in 2001 (SVG 1.0 Specification approval, Adobe SVG Viewer version 3 (ASV3) and bundling of ASV with Adobe Acrobat Reader 5), SVG was ubiquitous on desktop browsers, with the result that temporarily SVG took off like gangbusters, with tens of thousands of developers using SVG for various sorts of interactive graphics applications (flow charts, business graphics, and mapping). But SVG adoption dropped once Adobe abandoned ASV. Subsequently, the open source browser teams added SVG support (first Mozilla, then WebKit). With the open source project SVGWeb supporting older versions of SVG in IE68 and Microsofts announcement of SVG support in IE9, SVG has once again regained ubiquity, and developers are now (re)discovering the power and coolness of DOM-based scriptable graphics.
The future for SVG looks quite exciting, particularly when using SVG as a component of HTML5. The W3C, in collaboration with the browser teams and the community, is generalizing many of SVG 1.0s best features (e.g., clipping, animation, filter effects) into CSS so these features will also be available to HTML, and cleaning up SVG to make it easier to use (e.g., removing SVGs XML requirement). There is active discussion about going to the next level with vector and raster graphics effects, particularly ones that are able to leverage CPUs. Given the automatic update features of the modern browser, developers will be able to take advantage of cool new features almost as soon as they are defined.
Background : Jon Ferraiolo was one of SVGs principal architects. He was the primary author of the PGML submission that served as the starting point for SVG and was the sole editor of the W3Cs original SVG specification (SVG 1.0). While employed at Adobe Systems, Inc., he was the architect for several SVG-related projects at Adobe, including the Adobe SVG Viewer and Adobe Illustrators SVG support. He is now a Distinguished Engineer at IBM.
Alex Danilo
In the early days of the web, browsers were rapidly changing and competition was fierce. When the W3C sent out a call for vector graphics proposals for the web, a collective cheer from thousands of graphics people could be heard. At last, to be free of those ancient bitmaps and bring the web into beautiful resolution and independent glory. This was the birth of SVG.
As we know, Rome wasnt built in a day, and over the years SVG was massaged and honed to perfection by an army of enthusiastic graphics aficionados. The result is a gem thats polished and can glisten with vibrant color when viewed in the right light.
SVG enables vivid interactive experiences that adapt to any display size, a way to bridge images with meaningful semantics, a powerful synergy with HTML and the DOM and just looks so good!
Background : Alex Danilo joined the W3C SVG Working Group at the start of 2002 and is now the representative of his company Abbra. Abbras implementations both for mobile devices and web have always been at the cutting edge of the development of the SVG specification. Alex has very often produced the first proof of concept of new proposals for SVG. His current focus is development of a rich-media capable SVG engine for cross-platform application areas especially in resource constrained devices.
Cameron McCormack
It has been 10 years since the W3C Recommendation for SVG 1.0 was published, and having been involved in the SVG community for most of that time period, I can say with first-hand knowledge that SVGs fortunes have definitely been mixed. This is not an indictment on the technology itself, which is solid, but a historical problem of implementation availability.
In the early 2000s, there was a good deal of interest in SVG, as evidenced probably most clearly by the activity on the SVG Developers Yahoo Group mailing list, a forum that is still running today. Authors were creating visually rich, graphical, dynamic web applications with SVG before it became popular (or possible) to do so with other open web technologies. That this was possible at the time was, in my view, nearly entirely due to Adobes investment in SVG and their development of the Adobe SVG Viewer plug-in. It did not matter that browsers support for SVG was not up to scratch or did not exist at allthrough the use of the Adobe plug-in, SVG was available to everyone. (Technically not everyone, of course, as the plug-in was limited to particular operating systems and architectures, but for most authors this was good enough.)
The last release of the Adobe plug-in, a preview of version 6, was made available in 2003. The preview release was somewhat unstable, but demonstrated attractive new features, including a componentization model for SVG content whose fundamental ideas even today garner interest despite a number of false starts in standardization groups. However, for a long time after this release not a word was heard out of Adobe on their plans for development. This caused growing consternation within the SVG developer community, as progress of native browser implementations had been slow to catch up to the features and performance of the plug-in. Interest in SVG began to wane, and Adobes acquisition of Macromedia and the Flash platform only served further to fuel the notion that SVG was dead. The years following were the Dark Ages of SVG.