Introduction
N.B. This document is part of the Introduction to SVG training course. It is not an "official W3C document" and reflects the views of its author, not W3C.
As the implementers from both the browser and mobile worlds all seem to concur, SVG is a big spec, and not a trivial one to implement. No browser right now supports all of SVG 1.1, though a few have started to support aspects of 1.2 Full. The implementation from Adobe (IE/ASV) remains one of the most robust and speediest of the implementations (according to both my rather extensive experiments, Jeff Schiller's chart, and my timing experiments).
The shortcomings of ASV tend to fall in areas of scripting (not supporting certain modern DOM techniques), working within XHTML or in-line within HTML, support for <foreignObject> and other newer aspects of the spec, and in the rare bug related to complex interactions between script, clipPath and filters. In short, if one writes code to work with ASV almost all features supported anywhere are supported there. At the same time, many in the SVG community have begun to ignore ASV as a viewer platform, despite the lack of reliable estimates on the size of that audience. Hence newer content is often developed with no concern for ASV consistency, since, after all, it is a product that is no longer "supported."
Opera
Close to ASV in most areas and surpasing it in many, Opera's browser is widely viewed as the most advanced SVG viewer. Opera has done much to integrate SVG with emerging parts of HTML and CSS. It lags behind ASV only in areas of implementation of complex filters (it is occasionally slow and sometimes buggy) and in certain areas of <glyph> support. Its implementation is more standards-compliant than ASV's and best of all, bugs tend to be fixed in a timely fashion. Its speed, while lagging well behind ASV for many years, now surpasses that of ASV in many key areas involving the appending of simple shapes to the DOM. Almost all shortcomings that I observed in Opera three years ago have now been fixed. Opera has also aggressively implemented parts of the 1.2 spec (like support for flowing text), which is one of the most frequently mentioned shortcomings of SVG 1.1.
Firefox
Early tests with Firefox showed its implementation of SVG to be both slow and spotty [3]. Mozilla's decision about two years ago to staff their SVG development has, however, turned that inertia into substantial progress. Filter support within Firefox 3.6 is broad (with a few lacking features) with the major shortcoming being lack of declarative animation. However, the support for declarative animation within 4.0 beta leapfrogs ahead of the vestigial support for those things in webkit (and hence, Safari and Chrome). Firefox now has what I would call "serious support" for SVG, joining Opera and ASV in that category.
Webkit: Safari and Chrome
Support for SVG in Safari and Chrome is relatively new (circa 2008 when Chrome was introduced). Chrome was the first browser to launch with native SVG support from the beginming. There are occasional differences in support between the two browsers (notably in filter support and in some odd issues with rotated linear gradients), but generally something works in one if and only if it works in the other. Shortcomings are in the areas of certain advanced or complex filters, and in a spotty implementation of <animate>, having only picked what appears to be the low lying fruit. On the other hand, Chrome and Safari's implementations are lightning fast! In certain conditions, they run 10 times as fast as Firefox 3.6.
Internet Explorer
Prior to IE 9 there has been no native implementation of SVG within IE. Fortunately, the plug-in support was excellent! The topic is subject to some debate within the SVG community, however, with some developers deciding that IE support has been too difficult to maintain. From my own perspective, teaching in an environment where Windows and IE have a dominant foothold within the computing infrastructure of my University, and having cut my teeth with IE/ASV being the *only* development environment available, I do not share those feelings, and have found adaptation to the idiosyncracies of the other browsers (that have mutated and evolved but not disappeared over the years) to have been a source of inconvenience. The beta version of of IE 9 is already available.
The good news: it appears (from Jeff Schiller's chart [2]) to have pretty wide SVG support. It is hardware accelerated (through the GPU) and that means it is likely to be very fast in many areas.
The bad news: Microsoft will not be supporting declarative animation (SVG SMIL), filters, nor SVG fonts in IE9. They appear to be unconvinced of the merits of SVG SMIL (citing that Microsoft experimented with declarative animation in HTML some years ago but with little tracking, and that they don't see that many developments now that really need it). With all other browsers providing some support for <animate> though, it could just be a matter of time.
Filters
With the apparent consent of the SVG Working Group, Microsoft has advocated the attempted reconciliation of the CSS and SVG filter models. Those familiar with SVG filters, their power and complexity, may not see cause for concern here since if all that power can be brought to bear equally well across both the SVG and HTML worlds this ultimately gives authors more expressive flexibility. How the feedback loops intrinsic to SVG filters can be implemented in a DOM-less CSS remains to be seen, but that seems to be the current situation.
SVG fonts
Certain parties seem to be lobbying for WOFF which is apparently a much weaker version of fonts than SVG fonts, but accordingly easier to implement (see this summary of fonts on the Web). Whether WOFF meets needs of the communities that advocate for accessibility, multilingual support, and expressive power (as in fonts used for advertising) remains to be seen, but for now this area is an area little supported by any of the browsers, so Microsoft cannot exactly be faulted for having not moved into this area in its first implementation of SVG.
The bigger issue is that IE9 will only run in Windows Vista and Windows 7 (and presumably later versions!). With such a large installed base of Windows XP & 98 it is hard to say when IE 9 will actually become a large market presence. In the meantime, should developers continue to develop for IE/ASV? Many say no, but it is not clear to me that their position is well-reasoned. Throwing away a potential 40% of the market on grounds that are intrinsicially ideological rather than pragmatic would seem less than prudent. There are other possibilities though as Abbra's Alex Danilo announced a forthcoming SVG plugin for IE that he said should ship within a few months' time. In short, there is a bit of indecision about what to do in the IE environment until IE 9 becomes more widely deployed. Advocate ASV? Advocate another browser? The last strategy is not always a possibility in certain enterprise applications and on corporate Intranets where a lot of the private SVG consulting has been done in recent years. It is a topic that I hope the SVG IG will discuss with an open mind now that the polemic of Microsoft versus standards has now been, presumably, smoothed out to the satisfaction of most.
Last updated: $Date: 2011/12/09 17:16:28 $