Our upcoming Web 2.0 book is giving me the opportunity to have a closer look to the state of SVG.
After all kind of announcements for native SVG support in browsers, I was expecting that with my new Ubuntu Dapper distribution, SVG would be really easy to display.
The first thing I have tested is to display the clock that animates the front page of XMLfr: [download] in Firefox.
First test, first disappointment: the text “Réalisé en SVG” doesn’t show up in Firefox. This text is displayed on a path using a textPath element which isn’t supported by Firefox.
Second test, second deception: this was just not working.
Thinking that I needed to do more exhaustive tests, I decided to install the Abode SVG plugin which, fortunately is quite easy if you switch the native SVG support in Firefox using about:config as explained on Mozillazine. A very cool feature is that you can switch between native and plug-in support trough clicking on “svg.enabled” option without having to restart the browser.
After more tests and the very helpful mouseEvents SVG sample, I came to the conclusion that no implementation, including Adobe SVG plug-in, supports the “mouseover” and “mouseout” events correctly and switched to using “mousedown” and “mouseup” instead.
The result is a SVG document which (I think) is perfectly valid but works only with the Adobe SVG plug-in:
This SVG document works fine with the Adobe plug-in but doesn’t work with any of the other implementations that I have tested. Note that it is almost working with Opera 9.0b2 but this implementation doesn’t seem to support “set” elements on groups: if I move the “set” elements to the individual shapes I can get it working with Opera.
The full test report is a below:
|Test||Firefox 18.104.22.168 (native mode)||Adobe SVG viewer 3.01 beta 3||Opera 9.0b2||Konqueror 3.5.2||Amaya 8.5||X-smiles 1.0alpha1|
|SVG clock [download]||No support for “textPath”: the text doesn’t show.||OK||OK||No animation||The document is reported as non well formed!||No animation|
|Tags [download]||No support for “set”: no link are displayed and nothing happens when you click on a tag.||OK||No support for “set”: no link are displayed and nothing happens when you click on a tag.||No support for “set” not for the visibility attributes: all the links are always displayed. Furthemore, the browser crashes after a while when this document is left opened.||No support for “set” not for the visibility attributes: all the links are always displayed. The “text-anchor: middle” property doesn’t work either.||Crashes when there is a DOCTYPE declaration in the SVG document and throws an exception “Simple duration is not defined for this animation element” probably due to the fact that the set elements do not have durations when the DOCTYPE is removed.|
Also, the media type “image/svg+xml” seems to be a problem for the Adobe plug-in in Firefox even if, curiously, this isn’t systematic.
Wasn’t SVG supposed to be interoperable? The current situation reminds me on the contrary of the worse period of the browsers war even if I have no doubt that this time there are no political reasons behind that.
Mozilla explains that Firefox SVG is a subset of SVG 1.1, but not any of the official profiles (Tiny, Basic, Full).
Other implementations have probably similar policies and I can understand their reasons. However, I am wondering if these partial implementations do not hurt SVG more than they help.
The commonality between them is that, except Konqueror when it core dumps, they all fail silently when they encounter a feature that they do not support leaving users with the feeling that the document they are viewing is bogus.
When a user with a browser that has no support for SVG finds a SVG document, she/he is invited to load a plug-in. When her/his browser has one of these partial supports, she/he just moves away.