The Fall and Rise of SVG

The Fall and Rise of SVG

SVG certainly crashed and burned before it rose like a phoenix from the ashes…

Sometime in 1998, a former co-worker who had gone to work at Adobe came by my office at Bertlesmann to inform me of a brand new technology that she knew would excite me: PGML, or “Precision Graphics Markup Language.” This was the Adobe flavor of XML for Vector Graphics. As Jon Warnock put it at the time:

“The PGML proposal solves a growing need for a precise specification that enables members of the Web community to readily and reliably post, control and interact with graphics on the Web.”

I fell for it, hook, line and sinker, and ever since that time, I have followed the standards for XML-based vector graphics closely. PGML (mainly from Adobe) and VML (mainly from Microsoft), as well as a few other similar efforts (Web Schematics, Hyper Graphics Markup Language, WebCGM, and DrawML) soon merged into a “real” W3C standard, called Scalable Vector Graphics (SVG). This promised to serve as a format for rendering interactive vector graphics in Web browsers, which at that time (the era of Netscape Navigator 4.7 and Internet Explorer 5) was only possible with Macromedia Flash.

Completely obvious in the year 2000

What made SVG so cool? It could almost be considered “PostScript for the Web,” so it certainly made sense for Adobe to sponsor and support it in its infancy: with SVG (as with PostScript), art was primarily described via vectors, a method far more efficient (and more naturally “scalable”) than using raster images.

Vector vs. Raster

Yet there was an added dimension to the coolness: unlike PostScript, SVG was expressed as declarative markup in a standard markup meta-language, XML. Mere mortals could code something like:

<circle cx=”60″ cy=”60″ r=”50″/>

…in a text file, save that file, then load it into a browser and see the result. They could also write script against the SVG Document Object Model (DOM) in order to animate or modify the basic properties of the XML. Unlike the alternative then available (Macromedia Flash), this was all very transparent to the user. Additionally, because the format was text-based, the content was easily searchable. While initially a plugin was required to view it, the goal of the standard was native browser support.

To me, the rationale for this technology was obvious: I viewed it as an advance in web technology that would take over the world. Not long afterwards, I discovered the Yahoo SVG Developers Group, where similar moths fluttered around the very appealing light shone by SVG.

As ’99 rolled into 2000, I thought that SVG’s global dominance would manifest itself shortly.  Certainly by 2001, 2002 tops; it made so much sense, and web standards as of the 1990s had generally tended to be implemented within a roughly two-year horizon. But SVG’s “overnight success” was to take a few thousand more nights than I had expected. 2002 came and went without any of the ubiquity that Macromedia Flash was starting to enjoy at that time.

2003: enter the era of languishing web standards

We in the SVG community worked hard to define the standard, as well as encourage sensible and appropriate use of that standard in the software of the time. Browsers, obviously, were our primary target, but support from desktop graphics applications was also needed. There were initially bright signs on both fronts.

It was the best of times

As of 2003, Adobe had an SVG Viewer that rendered SVG in browsers, while Illustrator offered SVG support as an authoring tool and Mozilla had embarked on an effort to support native SVG in the browser. Even Microsoft Visio had SVG support. There were many powerful demonstrations of what SVG could do, from cartography to data visualization, even to flash-like sites.

Early SVG drawing application

There were also several books on SVG written at the time. Chris Lilley finished his introduction to SVG Unleashed with “Welcome to the Future”.

It was the worst of times

Yet it was starting to look like like the future might never arrive: the Adobe SVG Viewer (at the time, the only way to access SVG in a browser) was not widely distributed, and Microsoft failed completely to acknowledge SVG in their then leading browser, Internet Explorer 6. Without support from the most popular web browser, SVG remained stuck, effectively useless as a format for general web publishing. It was great for applications in very controlled environments, and it had an aesthetic appeal for geeks, but it remained obscure and outside the flow of mainstream usage. For the time being, the only widespread purveyor of vector graphics on the web was Macromedia Flash.

The two main forces of delay

A decade++ later, it’s easy to understand the main challenges that faced SVG, and see why it took so long for SVG to take over the world. I, for one, certainly didn’t understand these points, or predict their consequences back in the early days of SVG. But as always, hindsight is 20/20.

Web browsers

Browser wars – who really wants standards?

I remember the Mozilla of that time fondly – they had great intentions and were doing their best to implement SVG. It didn’t move quickly, but progress was steady, and native SVG (without plugins) was first proven out in their builds.

In 2002, Microsoft contacted me and offered to hire our whole company (er, both of us). My initial reaction was “why?” but it soon became apparent that they knew all about our SVG work. Whether planning to support SVG or not, it was clear that they were up to something. In the end, it turned out that although they followed SVG very closely, it was not with an eye to implementing it as a standard. Instead, Microsoft saw SVG as a technology to copy, something which they later arrogantly attempted with XAML, the markup language behind the ill-fated Silverlight technology. XAML bore a striking resemblance to SVG.

Meanwhile, Adobe supported the SVG viewer and provided SVG authoring support in their products, including FrameMaker, Illustrator, InDesign, and GoLive. However, they could do nothing to influence Microsoft to change their ways. With the extreme market share that Internet Explorer was commanding at that time, Macromedia Flash remained the choice of most designers/developers to render serious vector-based content. SVG may have been better technology, but market share was the deciding factor. In light of Microsoft’s dominance, Adobe’s support for SVG looked more like an experiment than a full-out effort.

“Standards are for losers”
— The cynical perspective

At a time when Microsoft’s IE enjoyed tremendous market share without SVG, and Macromedia had the only browser plugin users were known to actually install (thanks to their “right place at the right time” luck), why would either company support an open technology that could level the playing field? Those who supported SVG were the underdogs, running the gamut from engineers who saw it as the superior technology (and therefore inevitable), to businesses that saw it as a way to nip at the heels of huge monopolies that led the pack due to their proprietary technology.

Standards wars – all your text flow are belong to us

But even had the monopolies du jour embraced SVG (with bold disregard for their shareholders’ interests), SVG would still have been challenged. This is because it was one facet of the overlapping standards, two of which – HTML and CSS – significantly pre-dated the upstart specification. By the early 2000s, the W3C had proven itself far less than perfect, between standards that went nowhere (Xlink, for example), and standards that were bungled (XML Schema). The XHTML standard really shone as an example of W3C’s failings. The challenge of putting SVG in context among overlapping standards such as HTML and CSS was anything but trivial, a challenge compounded by the fact that the overlapping standards were in motion, and not necessarily heading in the most positive direction.

Wrapped text in SVGTake text, please – one of the most in-demand features that SVG 1.0 lacked was flowing text, text that would wrap when placed inside of a container. The SVG Working Group took this challenge on, only to discover that it wasn’t their responsibility. The CSS Working Group had already dealt with text in deep ways… between politics and the range of possible technical approaches, what was the role of SVG, exactly?

The Compound Document Format Working Group was formed in 2004 to work on documents with multiple formats, such as XHTML and SVG. This presumed native browser support: when trying to code SVG in the context of a plugin, there really wasn’t a good way to achieve “inline SVG” (SVG mixed with HTML).

The birth of the CDF effort was concurrent with the birth of HTML5, which was a rebellion against the XML-centric direction of HTML into XHTML. HTML5 took a different approach to reconciling these overlapping technologies, with the net result of making SVG even more overlapping by offering Canvas as yet another approach to rendition. Eventually the CDF was abandoned, but not without result: much of their work ended up contributing to HTML5.

Compared to a proprietary format like Flash, the interplay of multiple open standards over time presents a challenge to developers and designers who are trying to use those standards. It is not always easy to define best practices when the same thing can be accomplished in at least three different ways. Additionally, without a single plugin for rendition, developers are at the mercy of the quality and completeness of implementations in each browser.

2005: Adobe gives up on SVG

Adobe had long endured this life of the underdog, supporting a “loser” standard for years, and apparently grew tired of virtue at the expense of monopoly. In 2005, they announced the acquisition of Macromedia, their biggest (and arguably, only) competitor. This had negative side-effects for the SVG community: the SVG Viewer was soon deprecated (2006), and SVG features of applications such as InDesign were removed. SVG_Discontinued_01

With Adobe’s strong backing and significant engineering investment, Flash appeared to be headed for ubiquity: on PCs it was nearly universal (90-something percent market share) and on devices… well, those devices were still rather crude when it came to serious browsing or graphic rendition, so it was easy to imagine that Flash would live up to Adobe’s rosy roadmap for global dominance.

Flash was going everywhere, or so it seemed...

Rather than embracing SVG as an alternative, Microsoft pursued a blatant copy of Flash in their too-late-to-the-table Silverlight effort. Internet Explorer had zero support for SVG in versions 7 and 8.

While both Adobe and Microsoft pursued proprietary alternatives to SVG, the SVG Working Group still had its charter, and other “losers” like Mozilla kept pushing the technology forward. SVG improved as a standard with the 1.2 effort (including modest new features), as well as the parallel 1.1 effort (bug fixes from the rushed 1.0), both of which had gestated for years.

SVG 1.2 Tiny became a W3C Recommendation in December 2008, while SVG 1.1, second edition, mainly errata and clarifications in relation to 1.0, finally became a Recommendation in 2011.

SVG got decent support from Firefox and Webkit (and consequently from Chrome and Safari), making Microsoft’s IE start looking like something of a loner. This took place while its market share eroded, thanks to Chrome and Firefox, contemporaneously with Silverlight’s failure to gain a significant foothold.

Adobe Flash had attained a powerful position in desktop browsers, with Flash ads rampant and “rich internet applications” proliferating, but when it came to mobile devices, (offering quantum leaps in browser functionality following the release of the iPhone in 2007), Flash faced an uphill battle. SVG support came to the iPhone in September 2008, but Flash support was never to be.

2010: The meek finally inherit the earth

In January 2010, Microsoft announced that they were supporting SVG in Internet Explorer 9. Later that year, Steve Jobs published his “Thoughts on Flash”. It was the HTML5 standard, something of a soup of technologies inclusive of SVG, that stood as the only available alternative to Flash.

Adobe’s ambitions with Flash, AIR and the “Open Screen Project” represented a substantive threat to Apple’s “walled garden” and while Steve had good points about browser plugins being undesirable, Flash’s mobile performance being initially terrible, etc., the threat Flash/AIR represented to the App Store was the economic motivation to his newfound love of standards. With the iPhone and the iPad, Apple had the power to kill Flash, and SVG was just sitting there waiting (now in an HTML5 context) to enjoy the support it had long deserved.

Both Microsoft and Apple embraced/supported SVG fully, once it was politically expedient. The 2011 SVG Open Conference was hosted by Microsoft. This was surreal.

Carto.net SVG Example

To be sure, SVG had not changed much since 2000. When Internet Explorer 9 previewed, the SVG demos presented (such as the beautiful cartography work of Carto.net) were literally vintage pieces, circa 2001 and 2002. Generally speaking, these ran just fine on the iPad when it came out (literally 2001 code unchanged). One sad part of Microsoft having “embraced” SVG was that they refused to implement SMIL, a specification for animation that had been quite popular among early SVG developers. Even today, MS seems to be winning the battle to kill SMIL, as Google is now planning to follow suit.

SVG support, 2015

Still, the level of core SVG support across browsers and devices (as of 2015) is stunning. Basic SVG support is truly ubiquitous.

d3.js example

 

Libraries and frameworks for generating and working with SVG (such as d3.js) are proliferating, with some of them getting very robust. Today, SVG is supported by some 2 billion+ devices worldwide, while Adobe has returned to supporting it in graphics applications with huge advances recently: the CC2015.2 release on December 1, 2015 offers amazing SVG export from Illustrator (light years ahead of the initial export, which focused on round trip with Illustrator at the expense of real world usage) and SVG import to Photoshop.

Now that SVG is widely supported and native to browsers, and now that tools are moving forwards instead of backwards, the art of using SVG is more connected to the surrounding web technologies that it can now interoperate with in HTML5: Javascript, HTML, CSS, Canvas, and WebGL. The standard is moving forward again, this time with a more harmonious interaction with other standards and broader, faster, implementation: even text wrap is coming back. Fundamentally, SVG has attained the primary goals of its original vision, it just took a bit longer than some of us predicted.

Good things come to those who endure.

24 Comments
  • […] The Fall and Rise of SVG – Now that SVG is widely supported and native to browsers, and now that tools are moving forwards instead of backwards, the art of using SVG is more connected to the surrounding web technologies that it can now interoperate with […]

  • Here is another example of content from a URL converted to SVG and it can even be embedded….Check out http://edo.cr/kw0r43ro

  • Here is an example of PDF to SVG. We convert most formats to SVG and then we enable Collaboration, Redaction, eSignature and advanced Search. Our PRIZM CONTENT CONNECT v10.5 or PCC v10.5 is offered as an on-premise solution and is embedded in many world class 3rd Party applications. Publishers are using it as a collaboration tool to annotate content, as it is prepared and approved for publishing. Energy clients are using it to enable mobile viewing as it is build with a responsive Design and RESTFUL API and WORKFLOW.

    We have built our future around SVG!

  • […] The Fall and Rise of SVG: What many people who are recently discovering the advantages of using SVG for images don’t realize is that SVG has been around since 1999. Browser wars, standards wars, and acquisitions led to SVG languishing for years. […]

  • […]   […]

  • An interesting presentation. Having traveled in different directions during those years, I would tell a rather different tale of the history of SVG, but it would be correlated r=.707 with yours. Our periods of optimism would probably be directly inverse, however.

  • […] great overview of the history of SVG  […]

  • and this site’s logo is a bitmap…..

  • Junior Godoi

    Guys, the images from article are png because its a article about a technology not a demonstration. If I talk about flash (theory) I don’t need to make a flash based page. Focus guy, Focus!

  • […] great overview of the history of SVG  […]

  • IMNSHO SVG is completely broken:

    The SVG path, the only non-toy shape, is not XML, but a very awkward sub language with its own grammar; in it, the ellipse path element is very tricky and hard to use practically.

    Same goes for color specs: non-XML crappy sublanguage.

    Schema validation, in theory simple with XML, becomes impracticable.

    SVG and XML have failed to deliver, once again. Give me back Postscript/PDF with modern extensions.

  • Am I missing something here?
    All the images in this article are PNGs and SVGs.

  • And with all that SVG being supported by all browsers, all images on this page are PNG.

  • It is so typical of the evolution of software technology and the role of Microsoft. Somebody has a good idea, lots of other people also had the same idea previously but didn’t bring it to fruition; everybody tries everybody else’s ideas, mixing them all together to find out what works best. After three or four years there would be a fantastic standard which everybody likes and works a dream…

    Except along come Microsoft, pretend to want in to the party, then try to buy it out, then pretend they invented it, then make a total balls-up of its further `development’, and finally let it languish.

    Ten years later everybody realises that the original enthusiasts for the standard had it right in the first place, and, hey, let’s run with it.

    Fifteen years on, the world reaps the benefits, and starts to look forward to the next four, er, fifteen years…

  • Good history, I have always been a fan of SVG. However, this one statement is totally wrong and perhaps comes from a personal dislike of Microsoft:

    “Instead, Microsoft saw it as a technology to copy, something which they later arrogantly attempted with XAML.”

    XAML is way, way more than a copy of SVG. It is arrogant to presume otherwise. XAML is an entire markup language, of which vector graphics similar to SVG is but a very small portion. Given the undertaking, Microsoft chose to write their own vector graphics, probably for practical reasons, like the untenable situation of having a portion of your library dictated by a separate standards body. It would have been nice if Microsoft included some native support for SVG, but that did not happen.

  • One remaining issue for us at TheSpacePlan.com is the inability to effectively protect and prevent wholesale copying and modification of large scale SVG images. In cases where a large proprietary image is to be displayed, we’re forced to use low-res JPG or PNG with an image map. Eventually I hope to provide an AJAX driven dynamic image, where the entire image is never in the browser at one time but I’m not sure even that is a solution when the full high resolution image must not be made available to bootleggers.

  • […] SVG […]

  • Tony Anderson

    I just wanna say it is a great post. Many of us have followed SVG for years but without exactly know where it was going to.
    As a marketeer, I just wonder why so many people have not yet migrated their website pics to SVG.
    Scalable, cacheable, compressable, and fast to load… I see no reason for not using SVG everywhere.

  • David Hanson

    I’d love to see real investment in svg and it being the core rendering stack in the browser. Perhaps even being the shadow dom for html too.

  • svg will be popular in future

  • The text circle above illustrating SVG 2 is rendered with the raster file “text-shape-padding.png”. The irony …

  • I started my career with Flash. For about 10 years actually… It really is a cool tool to learn many facets of multi-media technologies. BitmapData, vector art, drawing API, audio, video APIs, masking, filters, ect… It’s a shame Adobe dropped the ball so badly with the technology. Since then, the only web technology that has interested me has been SVG. I was struck by how similar SVG was to Flash. For the last three/four months I have been using SVG for banner ads, and little interactive/motion pieces on various websites. I tend to use Greensock as an animation library because they have some seriously cool SVG plugins. I find it refreshing that SVG can accomplish much of what I was capable in Flash in terms of filters, masking and general layout and compositing. There are still some features I would love to see implemented though. Although, I am impatient because I am used to the speed at which Adobe introduces new features!

  • […] Source link […]

Leave Your Comment

Your Comment*

Your Name*
Your Webpage