How Ajax Changes the Game for SVG


Abstract


Much has changed with SVG since the first years of this decade. In the wake of the approval of the SVG 1.0 specification as a W3C Recommendation in 2001 and the release of the Adobe SVG Viewer (ASV), SVG became a popular web format for desktop computers, particularly among Enterprise web developers, who appreciated its openness, its rich feature set (including scripting, animation, and Ajax-like background HTTP requests to servers), its commonality with HTML, and its easy integration with XML workflows. In the 2002-2003 timeframe, SVG was on the verge of becoming a major Web format. However, with Adobe's abandonment of ASV, followed by an end-of-life announcement, and continued lack of SVG support within IE, SVG's popularity within desktop browsers plunged.

Now, years later, SVG is in the midst of a resurrection of sorts. On mobile phones, SVG Tiny has achieved widespread deployment and adoption. In additional to being an industry standard (not only a W3C standard, but also part of standards from 3GPP, OMA and JCP), SVG Tiny technically is the only widespread rich experience format (proprietary or otherwise) that is available on a wide range of volume cell phones and is performant on those devices. This is because SVG Tiny was designed and implemented by the mobile industry itself from scratch, versus various attempts to shove heavyweight proprietary desktop formats onto volume phones. SVG Tiny now ships on hundreds of millions of phones and is used to power many mobile applications, including mobile TV and video applications.

The SVG comeback also extends to the desktop due to strong SVG support in Firefox/Mozilla, Safari/Webkit and Opera, along with the emergence of Ajax libraries such as dojo.gfx that can deliver the SVG graphics model into IE by converting into VML or Silverlight. As mobile devices increasingly support desktop browsers, such as what we are seeing today with phones from Apple, Nokia, Google Android, and Opera licensees, SVG comes along for the ride and becomes a standard feature in future phones.

Another key development over recent years is the Ajax phenomenon. Since the term 'AJAX' was first dubbed in early 2005, the industry has seen an explosion of Ajax products and technologies, with hundreds of commercial Ajax products and dozens of open source Ajax projects. Within a little more than 3 years, Ajax has moved from an idea to a mature product category that is now an integral part of most company's web development efforts.

As a result, Ajax is big in the industry and SVG is part of Ajax. However, the landscape is complex due to major differences in SVG support within browsers and lack of SVG support within IE. Today, you really can't just use SVG on a cross-browser basis without using ASV with IE, and achieving interactive SVG across Firefox, Safari and Opera is highly complex. In this talk, Jon Ferraiolo will review current industry trends with regard to browser technologies and will demonstrate how far one can go today to use SVG by leveraging Ajax techniques to abstract away browser differences. Finally, Jon will offer predictions for what the future holds for SVG.


Table of Contents

Conception
Birth
Childhood
Early Adulthood
Maturity
Future

In the early years of the Web, it was obvious to various industry leaders that the Web needed to go beyond text and raster images and have strong support for 2D graphics. One of the first commercial efforts came from Jonathan Gay, who founded FutureWare in 1993 and delivered a proprietary technology called FutureSplash, which focused on frame-based animations for cartoons. FutureSplash subsequently was sold to Macromedia and rebranded as "Flash". In another early industry development, the venerable CGM format was adapted to the Web in the form of the open standard WebCGM specification. However, the WebCGM and the early versions of Flash were focused on particular niches. It was clear that the industry would benefit by a general purpose vector graphics format that could serve as a companion format to HTML. Chris Lilley was instrumental launching vector graphics work at W3C, presenting papers and ideas as early as 1994. One of his documents listed the requirements for a future "scalable vector graphics" industry standard.

By early 1998, some big companies (names to be listed later) became convinced of three things: (1) 2D graphics on the Web was going to be the next big thing. (2) 2D graphics needed to be expressed in XML (due to all of the excitement around XML at that time in history). (3) W3C standardization was important to success (based on strong evidence of strong engagement by Microsoft and Netscape in W3C standards activities in the years of 1997 and 1998).

As a result, four large companies (Adobe, IBM, Netscape and Sun) came together in April 1998 to submit PGML to the W3C. One month later, in May 1998, a different group of five industry giants (Microsoft, Autodesk, HP, Macromedia and Visio) submitted the alternate VML proposal. For the most part, PGML was an Adobe proposal that expressed the PostScript and PDF graphics models in XML, but then went beyond static graphics to include scripting, animation, transparency, symbols, reliable color, ligatures and alternate glyphs. For the most part, VML was a Microsoft proposal that expressed the graphics model used within Microsoft Office. Also in 1998, Bob Hopgood and friends submitted the WebCGM submission.

Given all of this interest in 1998 around vector graphics in XML, the W3C formed the Scalable Vector Graphics Working Group, which held its first meeting on August 31, 1998. The kick-off meeting was attended by approximately 40 companies, including all of the companies and people involved in the PGML, VML and WebCGM submissions.

The SVG standards activity was a huge effort. SVG included many complicated graphics issues, such as color models, compositing, timing models, fonts, and filters. But beyond the graphics complexity, SVG was the first real attempt at integrating many of the point technologies at the W3C into a new host language. SVG integrated technologies from countless other specifications: XML 1.0, XML Namespaces, DOM2, DOM2 Events, CSS2, SMIL (for timeline and animation), XLink (for hyperlinks and references), XPointer, and many others. The SVG Working Group discovered that there were many difficult questions about these other standards that were unanswered. As the first committee to face these questions, the SVG Working Group had to develop reasonable solutions to difficult integration problems in a manner that worked well not only for SVG but could be a reasonable precedent for other future standards efforts.

As with any standards activity, vendor interests played a major role. Some vendors such as Adobe were placing a large bet (at the time) around the success of SVG, and therefore pushed hard for rapid advancement of the specification. There were active attempts to sabotage the standard, but at best those negative attempts ultimately only succeeded in delaying the standard and decreasing its quality. In several cases, vendors had their one pet issue that they felt was critical to the success of the standard. These special requests tended to result in new feature additions to accommodate a particular vendor's requirements since in a standards effort it is often easier to say yes than to say no.

Among the vendors, Adobe played the most significant role in the development and birth of the SVG language. They provided the sole editor for the SVG 1.0 specification, implemented and delivered an outstanding browser plugin that faithfully implemented most features in the SVG language, and included SVG support within some of their products, particular Adobe Illustrator. Adobe also played a major role in evangelizing and promoting SVG to the industry, sending speakers to talk about SVG to numerous industry conferences.

Arguably, the official birthdate for SVG is September 4, 2001, when the SVG 1.0 specification was approved as a W3C Recommendation. On the commercial side, in October and November of 2001, Adobe released SVG Viewer (ASV) 3.0 (which included "Ajax"-like features for SVG pages to talk in the background with servers using HTTP Post) and Adobe Illustrator 10. In 2002, Adobe released two server products with SVG support, Adobe Graphics Server and Adobe Document Server, and shipped a new version of Adobe GoLive with SVG support. Earlier in 2001, Adobe had begun shipping Acrobat Reader 5, which included ASV2 with an auto-update mechanism. Acrobat Reader was installed by default on most desktop PCs. As a result, by the end of 2002, ASV was installed on over 200M desktop PCs. (Adobe pulled ASV from subsequent releases of Acrobat Reader.)

But as an infant technology, SVG was not consistently loved by one of its parents. In late 2001, Adobe changed direction and put its SVG initiative into maintenance mode. The SVG and open standards pendulum swung back and forth a few times at Adobe, which at once point allowed the public posting of ASV6 preview release, the industry did not see any additional formal releases of ASV other than security ASV3 security patches.

SVG grew to be used in many different workflows. The Batik open source project allowed SVG manipulation in Java, which enabled many uses of SVG outside of the browser. Several device vendors who needed vector graphics features picked a relevant subset of SVG (which was/is, of course, the industry standard) and included it as embedded software within their products. However, in terms of sheer numbers, the dominant use of SVG in the early years was to create SVG web content that was viewed within ASV.

Although Adobe had suspended most of its SVG efforts by late 2001, most of the industry was unaware due to lack of any formal announcements. Large parts of the industry assumed that Adobe was still behind SVG and they were highly positive about the technology and the quality of ASV3. Tens of thousands of developers built SVG web applications with dependencies on ASV, often using ASV features that were not yet ratified by the W3C, such as postURL() and context menus. The most common application for SVG was interactive information graphics, where XML data generated by a database was rendered as an interactive graphics application, typically with a large graphic in the middle of the screen and UI controls along the borders. As the user click on or hovered over an area of the graphic, different supplemental data would appear. Within Enterprise accounts, one of the common use cases was interactive process flow applications, where an intelligent flow chart editor was implemented using SVG and tons of underlying JavaScript, with a back-end server storing the result. SVG's popularity grew to the point that at SVG Open 2003 a member from the Microsoft Visio team claimed that 50% of their Enterprise customers either had SVG projects underway or were planning to use SVG. Ultimately, many major Enterprise software product included an ASV dependency for at least one of their components. For example, one release of the Oracle database administrator product had a performance monitoring feature that only worked when ASV was installed.

At Adobe, the pendulum swung back in 2002-2003 such that there was a more positive outlook towards SVG and other open Web standards. Adobe delivered ASV6 preview release around the time of SVG Open 2003, which included support for sXBL, video, grid layout, and a subset of HTML However, for various reasons, ASV6 was never productized.

In the years between 2002 and present, the SVG community has seen major decline in the use of SVG on the desktop while at the same time major growth of SVG installations on mobile phones.

Starting in 2001, the W3C began work on Mobile SVG, a subset of the SVG language designed to meet the need of lower-performance devices, such as mobile phones, and culminating with the Mobile SVG Recommendation in early 2003, which defined two subset profiles of SVG 1.1: SVG Tiny 1.1 and SVG Basic 1.1. SVG Tiny, which included basic vector graphics (paths, text, images, transformations) and declarative animation (i.e., SMIL Animation) was embraced by other standards organizations and often was a checklist requirement for mobile operators who had a commitment to open standards. The W3C continued work on SVG Tiny with a major update in the form of SVG Tiny 1.2, which added scripting, gradients and video.

On the non-W3C standards front, SVG Tiny was included within various other significant mobile standards, including MMS, OMA's standards for mobile browsers, J2ME, MPEG LASeR, W3C CDF/WICD and more recently 3GPP DIMS. Some of these related standards efforts have realized some success in the marketplace, such as the use of SVG Tiny for mobile video. The most significant of these other standards efforts in terms of SVG deployment were the combination of JSR226 and JSR248 (Mobile Services Architecture), which resulted in SVG Tiny becoming a requirement for J2ME, which is installed on most of today's mobile phones.

The marketplace result for SVG Tiny has been mixed. It has achieved a significant level of penetration and adoption on mobile phones, where hundreds of millions of mobile phones ship some form of SVG support, allowing companies such as Ikivo and BitFlash to build viable businesses. However, SVG Tiny has fallen far short of delivering on a write-once, run-anywhere value proposition to developers. Mobile developers cannot create SVG Tiny applications and expect them to run on a majority of mobile devices even though there is probably an SVG Tiny engine somewhere on the mobile phone. For some phones it is only available via J2ME, and on other phones, the SVG engine is not available to outside developers and is only used for the manufacturer own applications.

One significant challenge with SVG Tiny was the lack of a major corporate sponsor who was identified as the main driver for the standard. Depending on where the pendulum was at any given time, Adobe was either a strong proponent or a bystander regarding SVG Tiny. In comparison, J2ME had the full commitment of Sun and FlashLite had the full commitment of Macromedia. Some mobile vendors cared more about which large company was behind a particular technology than which format was endorsed by standards organizations.

But the most significant shortcoming with SVG Tiny in the marketplace has been its unavailability within mobile browsers. SVG Tiny had the potential to become both the real standard and the de facto standard format for mobile browsing. It had all of the right characteristics. It had the right feature set, yet was small enough and fast enough for volume phones. The critical missing ingredient was to convince mobile phone manufacturers to ship some form of HTML browser and SVG engine (e.g., Ikivo or Bitflash) where the browser could hand off SVG content to the SVG engine, coupled with SVG Tiny integration with Java for embedded application development. This would have provided the write-once, run-anywhere, rich-graphics solutions that mobile developers so desperately needed (and in fact still need).

It is now 10 years since the launch of the SVG Working Group, 7 years since the approval of SVG 1.0 as a W3C Recommendation, and 5 1/2 years since the approval of SVG Tiny 1.1 as a W3C Recommendation. In Web time, those are eternities. Within those years, for example, Google transformed from a startup into one of the largest companies in the computer industry.

SVG is now one of the old, established standards in the computer industry, and a new generation of technologies and people have arrived. SVG grew up in the period when the focus of industry hype was around XML, and which led to various derivative technologies such as XHTML, SOAP, WSDL, and countless WS* standards.

Now, a new generation of technology leaders has emerged which has largely rejected the former religion that worshipped XML and replaced it with a new religion based on real-life HTML. This new religion has amassed a huge following both among passionate individuals and among major corporations. In 2005, Jesse-James Garrett dubbed the term "AJAX" (asynchronous JavaScript and XML) to capture the technology thrust of the new religion. This spawned one of the biggest phenomena in the computer industry's history, where the hype around AJAX was huge and where countless products, open source projects, industry conferences, and books emerged nearly instantly. (Also, new industry groups, such as OpenAjax Alliance.)

At first, "AJAX" had a narrow meaning: using the XMLHttpRequest API to talk to a server in the background (using HTTP POST) to retrieve new information so that the browser application could make incremental screen updates, thereby avoiding the full screen redraw approach that characterized the first decade of the Web. However, "AJAX" quickly evolved into a broader definition (and often respelled as "Ajax") which now means the more general set of techniques for achieving rich user experiences in the browser using browser-native, open technologies such as HTML and JavaScript.

From a marketplace perspective, Ajax has proven to be a viable technology solution that fills many of the application areas that (several years previously) had been filled by SVG applications running on top of ASV3. As with ASV3, Ajax allows for rich user interfaces in the browser with the ability to send data to and from the server in the background using HTTP. Since most Web applications can get by with the rendering features found in HTML (i.e., text, UI controls, and images), and since Ajax is truly ubiquitous (since it is defined to mean the features that exist in today's browsers), Ajax has achieved huge penetration across the industry since Jesse-James Garrett's pronouncement in 1995.

The Ajax technology stack is on the move again and adding important features needed by Ajax developers, thanks to both passionate individuals and major corporations such as Google and Apple. At the W3C, the these advances are centered on the newly recharted HTML WG (with their HTML5 standards effort) and the Web Applications Working Group. The 2008 release of all major browsers included major new features found in HTML5 and other W3C specs, including postMessage() and local storage.

SVG has achieved a renaissance of sorts on the desktop as part of the recent revival of HTML. Today, Opera and WebKit browsers include native support most of the SVG 1.1 standard, including declarative animation. Mozilla today includes native support for most of static SVG 1.1, and is working hard to support all of SVG 1.1 in their next release, including SVG support for video. The lone browser holdout on the SVG front continues to be IE. One strong leverage point in SVG's favor with the IE team is the inclusion of SVG within the Acid3 browser compatibility tests.

The main shortcoming with Ajax is the lack of a good, cross-platform vector graphics feature. During 2008, OpenAjax Alliance brought Ajax industry leaders together to develop a prioritized wishlist for future browsers in an effort to help shape the future of the industry. By far the top vote-getter among the 55 features that were listed was 2D Vector Graphics. The Ajax industry leaders are now calling on the browser vendors to implement support for both SVG (DOM-based vector graphics) and Canvas (procedural-based vector graphics).

Some Ajax toolkits have done their best to fill the industry need for vector graphics within Ajax by shipping a cross-browser vector graphics JavaScript library. For example, the Dojo Toolkit ships dojo.gfx and dojo Charts. dojo.gfx is a JavaScript API that is modeled after SVG, but defined in terms of JavaScript objects. dojo.gfx converts the JavaScript graphics definitions into whatever technology that a given brower supports, which is usually VML on IE and SVG on other browser. dojo.gfx can also generate Silverlight and Canvas, which is the only option today for vector graphics on the iPhone. When Canvas is used, because of Canvas limitations, some features from dojo.gfx are unavailable. dojo.gfx is mainly about static graphics. In particular, dojo.gfx does not include support for SVG's DOM or its declarative animation features.

It is now 10 years since the launch of the SVG Working Group, 7 years since the approval of SVG 1.0 as a W3C Recommendation, and 5 1/2 years since the approval of SVG Tiny 1.1 as a W3C Recommendation. In Web time, those are eternities. Within those years, for example, Google transformed from a startup into one of the largest companies in the computer industry, and the Ajax phenomenon has grown from virtually nothing to a mature, mainstream technology.

Another key advance in the past few years is the increased processing power and memory for mobile devices due to the inevitable advances due to Moore's Law. Whereas a few years ago it was infeasible to run a desktop browser codebase on volume cellphones, it is now inevitable that most cell phones will include the equivalent of either IE, Mozilla, WebKit or Opera, and therefore be able to access and render the same Web content as a desktop PC. The most famous case in point is the Apple iPhone, which includes basically the same Safari browser as ships on its Mac desktop computers (with the one unfortunate difference that SVG support was not included in the iPhone 3G, although Canvas is supported). There are two open source browser codebases (Mozilla and WebKit, which is the engine for the iPhone), so there are few barriers to adoption for mobile phone makers to ship full browsers on their future devices. Therefore, browser technologies (HTML/JavaScript/Ajax) will deliver a ubiquitous, cross-device, rich user experience platform that developers can leverage to achieve write-once, run-anywhere application development based on open standards. It can be expected that, over time, many of today's SVG Tiny developers will migrate to the full Web Runtime.

The continued lack of SVG support in IE will continue to hamper SVG adoption. Until IE either adds SVG support (and furthermore succeeds in convincing the world to migrate off of IE6) or until a company with a strong reputation delivers a ubiquitous and high-quality SVG add-on to IE, the use of SVG on the desktop Web will stay low. In the meantime, for cross-platform, standards-based vector graphics within browsers, the world has to rely on Ajax libraries such as dojo.gfx.

For the Mobile Web, however, native browser support for SVG is likely to greatly to increase developer interest and usage in SVG; however, it will take some time before large number of mobile phones will ship SVG-enabled browser engines. Once that happens, the momentum on mobile phones will carry over to the desktop.