Lot of ups, lot of downs for SVG this past month or two. Let's recap them, shall we? I'll go over the major events for SVG deployment in the latter part of 2005.

Opera

First, a little over a month ago we got a preview of Opera 9 and it turns out that their SVG implementation has taken a leap forward to support filters, patterns, scripting, text on path and many advanced SVG Full features. When it is released I believe it will far surpass Firefox's 1.5 implementation. Some folks have told me that Opera is targetting full SVG support and plans to support CDF in a big way, which is fantastic news.

Mozilla Firefox

Which brings us to Firefox 1.5 being released last week with the first native, scriptable SVG implementation in a major browser. While this is genuinely good news for SVG as a web standard and reception by newbies to SVG has been favorable (even though confusion results from all the non-conforming SVG content out there), reception by SVG enthusiasts has been a mixed bag. Some people even think that Firefox shouldn't have turned on their SVG implementation by default.

Unfortunately, tentative roadmaps for Firefox show that Firefox 2 will be based off of the 1.8 branch, while Firefox 3 will be based off the 1.9 trunk. At present, any improvements to SVG support in Firefox are limited to the trunk (text on path, filters). This means that improvements to Mozilla's SVG support (other than perhaps bug fixes) will appear some time in 2007 (over a year away).

Adobe

Next, Adobe completes their acquisition of Macromedia and gives us a couple hints at what their stance on SVG is:

How does Adobe's acquisition of Macromedia affect Adobe's support of SVG (Scalable Vector Graphics)?
    Both Adobe and Macromedia have been part of the W3C working group that defined the SVG-t specification. While Flash and Flash Lite have gained critical momentum with customers and partners worldwide, particularly in the fast-growing mobile market, we recognize that both SVG and Flash have had success globally. As a result, Adobe will continue to support the display of popular graphics standards, including SVG-t and Flash, to meet the needs of customers and partners worldwide.

and

What are Adobe's plans for Flash Player and Adobe Reader?
    Our long-term plan is to develop a "universal client" by combining PDF, Flash and HTML in a single, integrated runtime. Of course, we will continue delivering the Flash Player as a small, efficient runtime for content and applications on the web, and Adobe Reader for viewing and interacting with PDF documents and forms. The integration of these technologies into a unified framework creates a ubiquitous platform that runs on virtually every device, and dramatically expands the opportunities to create compelling solutions.

Ok, speculation time (with apologies to John):

The first quote specifically mentions only SVG-Tiny. Any answer from Adobe which doesn't even mention their Adobe SVG Viewer, which supports SVG-Full and is still currently the best and most popular way to view SVG content in the majority of browsers, can only signal bad news. The mention of SVG-Tiny is significant because Macromedia already supported SVG-T so this just tells me they are keeping that support alive within the Flash Lite platform.

The second quote is interesting because they mention an "integrated runtime" support HTML, PDF and Flash, but no mention of SVG. David Mendels has confirmed that this "integrated runtime" will be a standalone piece of software codenamed Apollo, which means that Adobe is now planning to enter the "web browser" market. Will it support SVG?

A couple more facts: Adobe has been vocal about their frustrations with the pace of the SVG Working Group in the past. Adobe failed to attend the SVG.Open this year.

So what I read from Adobe is that they are giving up on SVG-Full but are forced to keep SVG-Tiny support around because of its wider deployment in the mobile arena. Not good news for the SVG community if true. It's a blow to the knees of "SVG on the web" just as native implementations are starting to show up.

Now I can't logically fault Adobe for putting their shoulders behind "Flash", since it is by far the more mature implementation and by far more widely deployed platform. And they get to control the pace of the specification. Flash is logically a better competitor to Microsoft's XAML next year.

Kurt makes the case that Adobe's exit from the SVG space could be a good thing as it opens the door for browser and other plugin developers to step up. While this is true to a degree, I worry that the space is getting tight.

I guess it should be made clear: This is really a battle for the future of web client development. Sorry for the excessive drama. Web applications are taking the next step in terms of user interface and people want to make money off of this. There are many sides to the battle: Microsoft with XAML, Adobe with Flash, Sun with Java, W3C with SVG and the Rich Web Client Activity, there's even the open source OpenLaszlo (which is based on Flash, if I understand things). My own belief is that there are too many competitors in this space. The web took off because there was one easy-to-implement standard: HTML.

Renesis

Finally, we learn from the EvolGrafiX team that their Renesis plugin has been delayed by months because team members have quit. Furthermore it sounds like if the plugin is ever actually released, it will only support SVG 1.2 Mobile. I don't know... GoSVG.net has been online for over seven months and aside from a (rather impressive) video we haven't seen anything from them. Is it vaporware? It sounds like even their presentation at SVG.Open didn't have an actual demo of their software... I think Renesis Pre-Alpha should be released, just to give the people some faith - it doesn't need to be a "Flash-Killer" at this point.

Final Words

What I'd really like to see is some upfront show of corporate support on some major sites and here are my suggestions:

1) Google Maps should now start using SVG for Mozilla and Opera in the same way they are using VML for Internet Explorer. Send the path data and let Firefox 1.5 and Opera 8 render it.

2) Flickr should create Image Badges in SVG.

Support for SVG from Google and Yahoo! would be a tremendous vote for SVG's continued existence on the web - and that would be a nice Christmas present. I'll put it on my list to Santa...

§189 · December 6, 2005 · Adobe, Firefox, Laszlo, Opera, Software, SVG, Technology, Web · · [Print]

7 Comments to “The SVG Roller Coaster”

  1. I agree the Adobe pronouncements look ominous, but they have been showing signs of not being all that interested in SVG since before they announced their absorption of Macromedia. I guess they originally were pushing SVG as a way to compete with Flash; now Flash is theirs they don’t want to dilute its market penetration. The lukewarm reception they had from the Mozilla project probably did not help, alas!

    It’s a great pity that, approximately ten years after the need for standardized vector graphics for the web was identified as a requirement, adoption is still so patchy. We need scalable graphics for future high-resolution displays, something that NeWS and Display PostScript flirted with in the 1980s, but which we seem to have forgotten since. Sigh.

  2. Well written article that summarizes the current situation pretty well. The only points I would take issue with are the “Final Words”. At this point, what business justification will drive Google and Flicker to adopt SVG? The only one I can think of is rendering for mobile devices, which is a compelling argument, I grant you–but aside from that, there is a vacuum of client support and no clamor for SVG outside the SVG community. HTML and other successful standards prospered because clients were fairly common, often free (in both senses), and did a reasonable job of rendering content consistently enough to be reliable. SVG now has several flavors, with most clients limiting themselves to the more limited subsets for mobile rather than full SVG. I recently read a pronouncement on SVG-Developers (Yahoo group) that decried how tough it was to support full SVG. I dunno about that, when I was the PM for Adobe SVG Viewer, we managed to do a pretty reasonable job even though we were developing the viewer before the ink was dry on the specification.

  3. One more thing worth mentioning. I know that there are many SVG “secret” projects that we don’t see public mention of. SVG is used behind the scenes in a variety of situations with great success, but outside the limelight. The public image isn’t nearly as good though. Some of the developers have recently abandon their SVG efforts. I know other pioneering SVG developers who have or are, considering hanging it up for a variety of reasons. This presents two problems for SVG adoption: 1) Loss of talent 2) Bad PR, or at least the lack of good PR. Without impressive, compelling SVG content what will drive future adoption? Even Adobe, once rich with sophisticated SVG tutorials and examples has diminished their tutorials and samples on their SVG Zone.

  4. Jeff Schiller says:

    Thanks, Michael. I agreed with all your comments.

    “I know that there are many SVG “secret” projects that we don’t see public mention of. SVG is used behind the scenes in a variety of situations with great success, but outside the limelight.”

    JEFF>>> This is the problem I think – SVG needs to be elevated to “limelight” status

    “The only points I would take issue with are the “Final Words”. At this point, what business justification will drive Google and Flicker to adopt SVG?”

    JEFF>>> What “business justification” existed for Google to use VML instead of contructing PNGs in their Google Maps? I guess it mostly had to do with IE’s transparent PNG support (?), but certainly it’s also less work for their servers and more elegant for the end user. Same things apply for SVG support. Granted the installed base of Internet Explorers is significant compared to SVG-enabled browsers. But support for SVG could be also considered a blow against Microsoft’s XAML technology… Google doesn’t have a competing technology here and they did financially back open source work on Inkscape in Google’s Summer of Code this year (which I was delighted to hear about).

    As for Flickr, well it’s harder to justify since they already use HTML (Ajaxified) and Flash, and Flash is so widely supported. It’s harder to build a solid business case for SVG support in Flickr other than “making friends with the SVG community” and “avoiding Adobe lock-in” 😉

    Anyway, I never said my “Final Words” were realistic but more like “wishful thinking” (as indicated by putting them on my list to Santa)

  5. Nothing wrong with a wishlist, Jeff!

    What I meant to say is that if I were the Google Local Product Manager 6 months or a year ago I would have had to consider my options. I could go with Flash, Java, SVG, or VML. SVG clients were scarce, and ASV hasn’t been rev’d, with the exception of some CYA security releases in almost 3 years (or 4 years if you are looking from today’s perspective.)

    90%+ of my audience had IE (with VML)…it was arguably easier to generate and open via APIs than say, Flash and anything is lighter weight than Java, not to mention both Flash and VML have greater adoption. So VML was a fairly logical choice with server side rasterization for non VML clients.

    Would I like to see Google Local use SVG? No question, but these decisions are rarely made on “religious” grounds. But as the Google Local Product Manager, I would have a pretty hard time justifying that at this time unless I wanted to target mobile devices. Of course Google could transcode SVG into VML for non-SVG based clients and rasterize it on the server for clients that had neither SVG nor VML support…is that cheaper and/or better? I honestly can’t say because I haven’t tried to crunch the numbers.

    Down the road, if Safari adds SVG support there will be three browsers with some level of SVG support. Assuming that they implement enough of the same SVG features, that will amount to something like 15% of the market. That’s not huge, but it isn’t small either.

    Of course none of these technologies are standing still. SWF has been adding dynamic content capabilities and a more robust application architecture. Adobe is pushing PDF into new areas and creating new clients (Apollo). Meanwhile, Microsoft is coming up with a fantastic set of vector based technologies and more importantly, impressive authoring tools, and promises that this will be supported across a wide range of platforms. As a Google PM I would also have to consider what’s best for the future of my product as well as what works in today’s environment.

  6. Chris Lilley says:

    Good points about Opera9 and compound document formats. They already render mixed XHTML and SVG content. This is one of the resons that SVG being in XMLis a win – mixing it with other things.

    In terms of projects under active development,you miss out WebKit, derived from the second round of SVG support in the Linux KDE browser,Konqueror; used by Apples Safari browser and alsoby Nokia’s own new open source mobile browser.

    Speaking of mobile, the very active implementation work by Ikivo and Bitflash should be noted too. eSVG from Intesis is reguarly updated, as well. And the SharpVectors SVG#product shipped a new relaese recently.

  7. Jeff Schiller says:

    Chris, I agree, Opera 9 looks promising. I don’t use Konqueror (with the KSVG/KSVG2 plugin) or Safari (WebKit) so I can’t personally comment on those, but I should have at least mentioned the news that developers have started the work on SVG support in WebKit, you’re right. For the record, I do occasionally check in with their progress over here.

    Anyway, with Ferraiolo’s clarifications regarding Adobe’s continued support of SVG (including improving Illustrators support of SVG), it seems that it’s too early to count Adobe completely out of the game and now the above Adobe section just looks like FUD…oh well…