SVG in Internet Explorer

an independent perspective

MichaelNeutze

Michael is known to the SVG community for the animated population pyramids that he developed with the National Statistical Institutes of the UK and Germany. He currently explores the use of SVG on his own and maintains a related website for data visualisation at vis.uell.net where he is focused on mapping german election data. He is an avid user of SVG Web, a JavaScript library that allows his SVG work to be seen by users of Internet Explorer versions 6 to 8.

Why care about SVG in Internet Explorer? – Aim of the paper

With SVG support finally coming to Internet Explorer 9 the technology is now ready for prime time, or is it? Probably not so fast. The initial purpose of this paper was to point out missing standards compatibility as there was fear among some in the community that ie9’s SVG implementation might be half-hearted. While the first platform preview had remarkable demos in terms of hardware acceleration, it lacked essential parts of the specification such as the viewbox attribute. This meant – and the author of this paper has been involved in such an endeavor for the ie9 testdrive site – that SVG had to be authored with severe limitations. Luckily with the release of the 3rd platform preview the doubters were proven wrong and a lot of the SVG content is now working right out of the box in ie9.

This paper’s topic is therefore now about the possible reality of content creators who want to deploy SVG and as it speculates about ie9’s adoption it will discuss avenues for the transition. The reader should not expect any testing results regarding performance nor any advice regarding browser preference. Choosing a browser is affected by so many aspects ranging from habit to personal preferences to IT policies, that SVG performance alone will hardly ever matter. There are also many examples where performance doesn’t matter that much but standard conformity does. A lot of SVG examples worked fine even on the ultra low power 100 dollar computer (OLPC XO-1), whereas many office workers sitting behind high powered multi-core machines would stare at a blank rectangle.

One of the main assumptions is that SVG is especially well suited in the enterprise and that is exactly where Internet Explorer has a high market share and a peculiar slow adoption when it comes to browser updates. As long as there aren’t similar authoring tools to Flash, designers will not be attracted by SVG in large quantities but business charting will.

The transition into an ie9 world where SVG support can be taken for granted

There are several clues as to why the transition period into an ie9 world, where SVG support can be taken for granted, will be a long one. For one, ie9 requires at least Windows Vista as the underlying operating system. Given how slow operating systems are updated in the enterprise – some may still remember the switch from WindowsNT to XP – this is a major stumbling block. According to Microsoft’s lifecycle page the extended support for Windows XP Professional ends April 2014 and in a recent article ZDNet claims Windows XP downgrade rights from Windows7 will be offered until 2015.

Apart from the OS version, even those ie customers who have the necessary prerequisites in terms of hardware and OS, have traditionally been slow to adopt. Unexperienced home users are less likely to install updates in general and ie updates are among the largest downloads in the industry. Corporate customers are even slower in adopting new browser versions as can be revealed using browser market share analysis. Apart from all the shortcomings of browser usage statistics, the following graph shows a pattern observed by multiple sources and will give some insights how different groups of customers respond to browser updates.

Fig. 1: Daily market share of Internet Explorer versions 6, 7 and 8

Looking at the daily browser market share there is a revealing pattern in general. Browser market share is different during the week than on weekends with an exceptional pattern during the year end holidays. While the patterns for ie6 and ie7 are on a different level they are in phase while the ie8 usage pattern is inverse to those. The plausible explanation is that during the week office computers dominate the internet usage statistics and on weekends the home computers are in the majority. Accordingly among ie customers home users are relatively early adopters while enterprise customers are not.

If SVG were a technology used mainly in games or other spare time activities the aforementioned update characteristics wouldn’t matter that much. But given that there are many hints that SVG could have a strong place in business applications, content creators should prepare themselves for a few years to come before relying solely on ie9.

There are several options for the transition period but plugins are certainly none of them. Especially in the enterprise environment relying on plugins is only an option for inhouse content. As long as one targets users in several environments even with a lot of evangelizing you will not be able to get all the users to install plugins, especially if they are only needed to display SVG. It's a different story for plugins like Flash or Silverlight that have a much broader range of functionality or in the case of Google's Chrome Frame where you frame a Webkit rendering engine with ie so that you can add functionality without disrupting user's habits in terms of bookmarks and other preferences.

Shim Technologies / Javascript Libraries

To bridge the gap until Internet Explorer Versions 8 and below are extinct or at least have a negligible market share, content creators have several options if they want to target the broadest possible audience.

Typically these days JavaScript libraries are used to abstract away differences in browser implementations and adding features major browser vendors haven't yet implemented. The advantage above plugins is clearly that users don't have to care about technology and can enjoy the 'it just works' experience.

Vector graphics are among those features. While the level of SVG support in current browsers other than Internet Explorer can be called sufficient for most use cases, Internet Explorer up to version 8 offered natively a vector language called VML, that while similar in its ambition to SVG doesn't offer the exact same feature set.

Before ie9 most JavaScript libraries tapped into the VML capabilities of Internet Explore to offer vector graphics for those users, thereby inventing their own JavaScript based graphics syntax. Below will follow a short discussion of some of those libraries, the author has been experimenting with. It is by no means a complete overview of available or suitable libraries and it will not go into detail which of the chosen syntax is superior to one another but offer some information for developers who are new to this and need to decide which route they want to go.

While the aforementioned approaches using VML in Internet Explorer as an auxiliary solution have been quite successful for basic charting, performance has been a major issue for more advanced use cases such as mapping.

A different way of adressing SVG support in the existing versions of Internet Exlorer is the SVG Web project, which aims at supporting as much of the SVG 1.1 specification as possible by rendering standard SVG markup with the Flash plugin. The project was showcased during SVGopen 2009 and the author will recommend this as the preferred solution for authoring content that will be ready for ie9 as it comes closest to how ie9 will support mixing SVG in HTML.

As of August 1st, 2010 and the 3rd platform preview of Internet Explorer the following JavaScript libraries have a different level of how well they can cope with ie9. All projects are well aware of ie9's SVG and Canvas capabilities and will support it, but right now it is still a moving target. Finally this overview should draw attention to where in the world of JavaScript libraries development is needed to cater for an Internet Explorer ecosystem that for a while will have very different levels of vetorgraphic support.

The Dojo Toolkit: GFX

In its own words: "Dojo saves you time, delivers powerful performance, and scales with your development process. It’s the toolkit experienced developers turn to for building great web experiences."

The decision for using dojo is usually not done for reasons of vector graphics alone. The self description covers the direction quite well and indeed the 'experienced developers' part of it should not be underestimated. While all the APIs are well documented and there is loads of professional support available for it, for the casual user or novice the lack of simple examples and tutorials when it comes to graphics can be a bit of an issue.

Dojo is very well maintained, can be loaded from a CDN and is available through Google APIs.

The dojo toolkit offers several moduls of which "dojox.gfx (GFX) is a cross-platform vector graphics API. It loosely follows SVG as the underlying model. GFX helps to isolate your application from the many native vector graphics implementation differences across all modern Browsers."

GFX is unique in that it can use the Silverlight plugin as native renderer where available. As of the current version 1.5 there is also experimental support for the SVG Web library (see below) that renders SVG using the Flash plugin.

As of August 1st, 2010 the dojo library isn't yet compatible with ie9pre3, in fact ie9pre3 doesn’t even render the project homepage in ie9 mode. But according to dojo developers they are fully committed to support ie9 once it is available as a full browser.

Raphaël—JavaScript Library

In its own words: "Raphaël is a small JavaScript library that should simplify your work with vector graphics on the web."

Raphaël is a smaller project than dojo as it is also much narrower in scope. Of all the JavaScript libraries it offers the most pleasant project page from a non-programmer perspective. The overall design of the page, its quickstart tutorial right at the beginning and beautiful demos make for a very good exerience that recently got its blessings from an A List apart article: "Note that Raphaël relies on feature detection rather than user agent (UA) sniffing" they say which is probably why most demos already run fine in ie9pre3.

JSXGraph | Dynamic Mathematics with JavaScript

In its own words: "JSXGraph is a cross-browser library for interactive geometry, function plotting, charting, and data visualization in a web browser."

What Raphaël is to designers, JSXGraph is probably to mathematicians. The project page has huge resources devoted to examples with a special emphasis on didactics in math education. Their use of the VML renderer in Internet Explorer version 6 to 8 is very powerful. Among the many showcases on their project page are two examples that were derived from the author's work, namely an election atlas and an animated population pyramid. So even some complex mapping geometries can be handled with the native VML renderer of ie6 to ie8.

SVG Web

In its own words: "SVG Web is a JavaScript library which provides SVG support on many browsers, including Internet Explorer, Firefox, and Safari. Using the library plus native SVG support you can instantly target ~95% of the existing installed web base."

SVG Web lives on Google code and has therefore the ugliest project page of all. But lets not be deceived by that. This project gives real SVG support to Internet Explorer Versions 6 to 8 if they have the Flash plugin installed. Again that is a bigger 'if' when it comes to the enterprise market but the advantages against the VML renderer are huge, especially with regard to future development and the upcoming ie9.

While the libraries discussed so far invented their own vocabulary that's specifically optimized for the intended purpose, there is no denying the fact that it just isn't SVG markup. There are only so many ways to draw a circle, but one shouldn't underestimate that not all vector graphics are created programmatically. With SVG Web every drawing done in Inkscape or Adobe Illustrator can be used instantly like this:

Keep in mind that the above example works in plain HTML and doesn't require the XHTML doctype. Between those script tags any standards compliant SVG markup is welcome and already most of it will work as intended. It is this mixing of SVG within plain HTML that is supported by ie9 that makes the SVG Web syntax so close to what is needed for later code re-use.

There are some limitations in SVG Web with regard to styling but work has already begun to implement CSS styling capabilities. Also SMIL based animations are beginning to be available.

A side note to the load event: Starting with the dracolisk release (April 9, 2010) SVG Web has its own 'onsvgload' event to mark when SVG Web is loaded. This is a breaking change that was necessary for the compatibility with JQuery. More information is available in the excellent Quickstart Guide or the very helpful and still manageable Manual.

For developers who don't have permanent access to Internet Explorer there are provisions to force the Flash renderer in every browser which gives an approximation of how projects will turn out in Internet Explorer Versions 6 to 8. Up to the dracolisk release (April 9, 2010) Version 9 of the Flash plugin was sufficient but recent work will make use of capabilities introduced with Flash 10.

For technical reasons SVG Web cannot be run from a CDN and also not from the file-system. The SVG Web project addresses this by providing a small preconfigured webserver with each release and also a tool to check if the server for deployment is configured correctly with regard to mime-types.

SVG Web is currently not compatible with ie9pre3 and volunteers are needed to help.

While SVG Web is expected to switch its alpha status to beta with the next release in time for SVGopen 2010 it is already quite mature, as can be seen in the open: Showcase examples include the Star Atlas, an Animated Population Pyramid as well as the author's own Election Atlas.