Too many SVG profiles

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: <em> You need either a browser that supports SVG or a <a href="http://www.adobe.com/svg/viewer/install/">SVG plug-in</a> to display this image. </em> [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.

Beginning to wonder if all that would be as easy as I had thought, I have developed a sample document showing the relations between the tags in the RSS channel of the book site.

I wanted to show the level of animation that can be done declaratively without a single line of Javascript and I have used the “set” element.

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:

<em> You need either a browser that supports SVG or a <a href="http://www.adobe.com/svg/viewer/install/">SVG plug-in</a> to display this image. </em>
[download]

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 1.5.0.4 (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.

I could probably get this sample working on most of these implementations by switching to Javascript animation and carefully testing against each of them, but is that something we really want to do again?

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.

Share and Enjoy:
  • Identi.ca
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Add to favorites

2 thoughts on “Too many SVG profiles”

  1. Weirdly enough, I am testing it right now with Firefox 3.05, and with Adobe SVG the text is not shown in either example. With native support the text is displayed, but the mouse event does not work. Bleh…

Leave a Reply

Your email address will not be published. Required fields are marked *

Enter your OpenID as your website to log and skip name and email validation and moderation!