Microsoft Communities
Posted By: Joshua Allen | Oct 17th, 2007 @ 7:05 PM

I recently encountered a link to this blog post, in which the author suggests that Microsoft and Adobe are colluding to kill SVG, the web-standard way of doing vector graphics. Of course, I had already seen speculation of Microsoft being the bad guy in order to promote XAML over SVG; and speculation of Adobe being the bad guy in order to promote Macromedia over SVG. But I hadn't seen speculation that placed emphasis on EPS and WMF formats, or which combined our supposed combined self-interest in killing SVG.

As much as I love a good chainsaw story at Halloween, I want to set the record straight. I'll help you see past the speculation by sharing some first-hand history, and then close with some comments about potential futures.

First, a quick summary of the current situation: SVG is a cross-browser, cross-platform way of doing vector graphics and animation. Flash provides a cross-browser, cross-platform way of doing the same thing. And Silverlight also allows cross-browser, cross-platform vector graphics and animation. All three are mutually incompatible (more on this later). Flash and Silverlight are "proprietary", controlled by the two largest vendors in the PC ecosystem. SVG was controlled by W3C from the start, and thus considered more "open". By all appearances, it sure looks like W3C vs. Adobe vs. Microsoft.

A Quick History Lesson

Appearances can be deceiving. For starters, the idea of combining vector graphics and animation is pretty obvious. There were already common runtimes for doing this before the web existed; primarily in the CD-ROM media industry. So it's a bit silly to assume that there would be only one, or that W3C, Adobe, or Microsoft would have originated the idea.

Additionally, Ryan's ars technica article made the common mistake of assuming that products which appear in market later are reaction to products which came earlier. He argues that Silverlight should have used SVG instead of XAML, since SVG came first and has some perceived overlap. The insinuation is that Microsoft looked at SVG and said, "screw it, we'll re-invent the wheel!"

But that's not how it happened. I was on the XML team during the time that XAML was being created, by the then "Avalon" team. At the same time as we were baking XML into Avalon/WPF, we were all enthusiastic early adopters of SVG. Chris Lovett wrote an SVG plugin which we used until the Adobe plugin was released, and we used SVG for all of our diagrams within our specs. Even by the time that WPF shipped several years later, nobody considered XAML to be an "alternative" to SVG. At the time, the conspiracy theorists accused us of trying to kill XForms, not SVG. XAML was designed to be able to replace full-featured applications, not web pages (which at the time were still primarily "documents" instead of "applications"). Silverlight inherits XAML, which was designed from the start to support full-featured rich applications. It's really that simple.

The overlap between SVG and Flash was historically more pronounced, since they were both focused on running within web documents. But again they came from different starting points. Flash didn't use markup, and significantly pre-dated SVG. Heck, back in 1996 we even killed a project at Microsoft that did much the same thing.

Worlds Collide

The world is different today, and SVG, Flash, and WPF/Silverlight have adapted. Flash is now adapting to support markup, the same as SVG. WPF already supported markup, and by moving into the browser in the form of Silverlight, presents another apparent challenge to SVG.

So, is Adobe going to retool Flash to be purely based on SVG? Will Microsoft replace XAML with SVG? Not a chance! Both product lines are relatively mature, and have good momentum; so neither company is going to abandon or randomize existing base.

Does this then imply that Microsoft or Adobe would like to see SVG die a quick death? Absolutely not! Adobe makes money from tools, and their tools still support SVG. By the same token, Microsoft has always thrived on diversity of developer choice -- we ship tools that support AJAX and JavaScript, as well as multiple programming languages. The more things you can code against, the more value you get from developer tools.

Finally, at the end of the day, it's all just markup. That's why it was easy to support SVG in Expression Blend. In fact, you would think it would be possible to transparently convert SVG in the page to XAML, and then have Silverlight render it, all without the user knowing. As a matter of fact, Sam Ruby took an XSLT written by Toine de Greef, and did exactly this! Of course, there are a number of SVG browser plug-ins available for IE, but this is a pretty powerful demonstration that markup and web standards allow these worlds to better work together.

Tags:
Posted By: jongalloway | Dec 6th, 2007 @ 3:14 AM
I don't believe Expression Blend imports SVG, just Expression Design. Correct?

Since portions of SVG and XAML are very similar, it's unfortunate that WPF and Silverlight don't have native support (albeit limited) for SVG. For instance, it'd be nice if Silverlight had a "LoadFromSVG()" the same way it has "LoadFromXaml()". I wouldn't care if it just supported text and simple paths, it'd be helpful and would show at least some thought towards supporting existing vector graphics standards. I believe it would also encourage adoption - right now the solution to using SVG in Silverlight is to buy one or more Expression products, or hunt around for some random, unsupported utility or webpage. That's not the best way to encourage broad adoption of the Silverlight platform.

I wrote a bit about this back in June; unfortunately I think most people assumed I was just complaining about WPF not using SVG (which was not my point at all).
http://weblogs.asp.net/jgalloway/archive/2007/06/05/silverlight-and-xaml-have-you-guys-met-old-man-svg.aspx
Tags:
Posted By: Joshua Allen | Oct 19th, 2007 @ 12:24 AM
@kmontgom: in the XML team, we were writing all of our specs in XML to dogfood (as in "eat your own dogfood) the process.  By the same token, the office team also built tools for XML document authors, so they wrote specs using InfoPath and XML.  SVG was designed to work well in XML documents, which is why we liked it.

Conversely, Avalon was part of Longhorn team (Windows OS), and they were NOT building a product intended for making XML documents, so they didn't have a good reason to dogfood XML authoring.  So they gravitated to just using MS Word for their specs.

Also I am sure SVG was used other places besides just specs -- I only used the specs example to show that there was never any hostility to SVG.  MSFT still considers SVG to be positive to neutral, and I bet Adobe feels exactly the same.
Tags:
Posted By: kmontgom | Oct 18th, 2007 @ 2:19 PM
... you never do say why the WPF/Avalong team stopped using SVG.
Tags:

Page Navigation