preventing the death of svg
September 12th, 2004 by Dylan
My thoughts on how to save SVG.
Update: I have been persuaded by the community to point out that SVG is not dead, is gaining strong support in the cell phone market, and will finally be enabled by default in mozilla 1.8. SVG itself is a great and very promising technology… I am simply frustrated by the current lack of widespread browser support. And maybe Adobe is considering open sourcing their SVG implementation based on the slashdot story today about Adobe forming an open source strategy.
Scalable Vector Graphics (SVG) is a promising recommendation, providing a rich XML syntax and language specific DOM bindings for the drawing of graphics. However, this standard has stagnated for the past several years for at least the following reasons:
- Lack of native support in mainstream browsers (mozilla is working on partial support, with widespread release rumored for late 2004 or early 2005)
- Fragmentation and apathy in the plug-in vendor market (Adobe has not publically released a signficant new version of non pre-alpha code since 2001, Corel has discontinued development, etc.)
- The fear of Microsoft's XAML (and WVG) has prevented development effort (one of the leading SVG JavaScript developers, Kevin Lindsey, has shifted his efforts to XAML/WVG, and of course Microsoft is not supporting the SVG recommendation)
- Major open source browser vendors have not embraced the recommendation, complaining that the specification is flawed and too complicated (while they may be correct, they have done too little to fix the spec.; it can be argued that the SVG Working Group is one of the few remaining W3C groups that actually tries to tackle the hard and interesting problems). A more modular approach the recommendation than what they today would be useful if browser vendors were involved in this process.
- Adobe, a company that made the strongest initial push for SVG adoption, has not devoted resources to the project that are needed for it to succeed. In fact, their organizational direction for SVG is at best unknown, and at worst abandoned.
- Apple prefers to ignore SVG, and instead implement their own vector specifications for vector graphics in Keynote, and client-side drawing with the proposed canvas element, that provides parametric drawing capabilities within a box element.
The current situation of SVG support is very disappointing, as I personally know a couple of the people that worked on the team to promote SVG. I have no insider information about their current plans. To me, it appears that Adobe has effectively abandoned the market with an incomplete implementation of an SVG viewer, one that remains the best and most widely used on the market, thus preventing other companies from investing resources into similar projects for fear of Adobe restarting development efforts. Community support is waning as champions of SVG such as Michael Bierman and Niklas have not updated their SVG blogs this year, probably because there is no current progress to report. SVG Open 2004 happened this past week, yet the descriptions of the talks seem terribly out of touch with the market (i.e. "since SVG is widely used on the WWW"). Most uses of SVG are currently limited to intranet applications, server applications with Batik, demo sites, or rare instances where sites offer a compelling enough benefit that requires the end user to install an SVG viewer.
So is it possible to revive this once promising recommendation? Maybe. A unique solution in my mind would be for Adobe to donate their codebase to mozilla, with the stipulation that they continue to support a plug-in solution as well as a native solution. The plug-in could be done through the Gecko Runtime Environment. This would offer many benefits to Adobe and the world:
- Adobe's codebase will not be lost to the world, and Adobe can still profit off of Illustrator sales.
- mozilla would be asked to manage the codebase as both a stand-alone plugin for any browser, and as a module to add native support to browsers such as mozilla, safari, and opera. And they could offer the plugin as a backport for older versions of mozilla.
- Adobe would develop goodwill with the open source community, and gain the other benefits of open source such as reduced maintenance cost for maintaining the SVG code base through third party development, and driving the direction of the product.
- Adobe would no thave to deal with the normal headaches of setting up community support for an open source project.
This of course would depend on the Adobe codebase being something that mozilla could actually use, which I am in no position to evaluate, even if I had a copy of their source code, which I do not. However, it seems like a dramatic solution such as this one is the only way to save SVG in the browser.
[…] A lot has changed for the better since my post four years ago on preventing the death of SVG. […]