SVG and Browser Support Part 2

Now that I’ve determined the time to use SVGs in the online version of my Inkscape has come (see previous post), the question becomes what is the best way to do it? The primary concern is to provide a graceful fallback for browsers that don’t natively support SVGs or are missing some required SVG feature (e.g. lack of filter support in IE9 and Safari 5). There are some criteria for choosing which method to use. Since I do my illustrations in Inkscape, Javascript libraries like Dojo, Raphael, and JSXGraph that create SVG or VML content depending on the browser can immediately be ruled out. Another Javascript solution: SVGweb uses Flash to display content in browsers that don’t support SVG. I don’t like this solution for a number of reasons. I don’t want to require my readers to install Flash, I would like to avoid using Javascript, and I don’t want to pepper my HTML with [if IE] conditionals necessary to get the <object> tag to work in IE. There are a number of plug-ins that support SVG such as the original Adobe SVG viewer (ASV). I don’t want to require my readers to install plug-ins and none of the plug-ins are very good solutions (ASV, for example, is no longer supported in addition to having other problems like not supporting the <object> tag). Actually, there is one interesting plug-in, Google Chrome Frame (GCF). This plug-in can replace the renderer in IE6, IE7, or IE8 with the renderer from Chrome. By adding one <meta> tag to a web page (or making a small change to the server configuration) you can suggest that the page be rendered using GCF. No other changes to the HTML need to be made. If GCF is installed, it is used; if not, no harm done. Having eliminated the above options, we are left with using standard HTML or XHTML. There are five ways to include SVGs in HTML and XHTML, four of which we can easily dismiss:

• Inline SVG: Requires XHTML or HTML5, neither which are supported by IE prior to IE9. In addition, as all my figures are in separate files, it makes no sense to inline them.
• <img> tag: Doesn’t support interactive SVG. No fallback method.
• <iframe> tag: On its way out in HTML4 and XHTML, but resurrected in HTML5. Intended in HTML5 to sandbox content from other sources. Again no fallback method.
• <embed> tag: Never in any HTML or XHTML standard but widely supported. As a matter of practicality, included in HTML5. Intended for content that needs a plug-in (this was the method used by ASV). Again no fallback method.
• <object> tag: In both HTML and XHTML standards. If the content referenced in the tag cannot be displayed, the content between the opening and closing <object> tags is exposed providing a simple fallback method. This is our obvious choice for including SVG content.

So, how does one use the <object> tag to provide fallback? Here is an example: <object type=”image/svg+xml” data=”svg_button.svg”> <img src=”svg_button.png” alt=”SVG Button”/> </object> But this has one problem: it displays with scroll bars in Chrome 6. The scroll bars can be avoided by adding width and height to the <object> tag: <object type=”image/svg+xml” data=”svg_button.svg” width=”300px” height=”100px”> <img src=”svg_button.png” alt=”SVG Button”/> </object> In fact, things get quite tricky with getting the SVG displayed correctly. All the browsers treat SVG included by the various tags differently as can be seen by this handy test page by Jeff Schiller. This is a known problem by the SVG working group and work is being done to clarify the correct behaviors. I am working on my own test pages to investigate SVG integration issues. There is an HTML version and an XHTML version. So we are almost there. The one things missing is what to do about the lack of SVG filter support in IE9 and Safari 5. That will be the topic of a future post.