Guide to Deploying SVG with HTML

Early in 2005 I started getting interested in SVG, a web standard for vector graphics on web pages. My efforts in this direction were first sparked by a friend and later by the fact that modern browsers like Firefox and Opera have introduced SVG support. This entry is to serve as a guide so people can learn from my experiences. It was originally published in Dec 2005, but I will continue to update it as more items occur to me. It was last updated in Jan 2007.

[Edit: Updated 2007-01-19 for ASV Workarounds]

Introduction To SVG [TOC]

Since the very early days of the web, HTML has the capacity to display text and hyperlinks inline with graphics. For the most part, graphics have been GIF, JPEG and more recently PNG, which are all raster graphics - meaning the image file contains the pixel information that should be displayed. SVG and other similar formats (like Microsoft's VML) describe vector graphics, which describe their images in terms of mathematics (i.e. they tell the browser how to draw the image). The benefits of this are that vector graphics display perfectly at any resolution (i.e. "scalable") and, with some exceptions, can be described in less disk space. The tradeoff is some interpretation cost (i.e. rasterization) at the client end. With upcoming hardware acceleration (see OpenVG) this could be alleviated also.

Anyway, all that aside, if you need a brief introduction to SVG, please feel free to read my first two SVG Kickstart Tutorials: One and Two. They give an overview of basic SVG functionality including how to draw simple and complex shapes, tools you can use and why SVG is important. This blog entry will be focused on integrating SVG into your web pages and the current difficulties imposed by various platform implementations quirks and differences.

SVG Implementations [TOC]

At the time of my original foray into this experience (Spring of 2005), the most well-deployed implementation for SVG by far was Adobe's SVG Viewer (known as ASV), which is a plugin for most web browsers. In the last couple years, both Mozilla and Opera have included native SVG support and Safari is working away on it. As a result of my target implementation platforms for SVG are primarily :

• Internet Explorer 6 (IE6) with Adobe SVG Viewer 3.0x and ASV 6 (pre)
• Firefox 1.5+ with native SVG support
• Opera 9+ with native SVG support

Note that Konqueror also has some support for SVG which is steadily improving.

Ok, here are some of the issues you'll face when integrating SVG with your HTML pages:

How To Include SVG Within HTML [TOC]

There are actually a lot of potential choices here. The following elements could support referencing an SVG image within an HTML page: <object>, <embed>, <img>, <iframe>. Furthermore, if you want to use an SVG image as a background or a list bullet, the CSS 'background-image' and 'list-style-image' are also candidates.

Now here's the ugly reality: No implementations currently support HTML <img> or CSS 'background-image' and 'list-style-image' [Update 2008-02-16: Opera 9.5 will support this]. This is unfortunate, since providing scalable backgrounds to <div>s within HTML pages could be a great way to get rounded corners on web pages instead of ugly hacks like this or waiting for CSS3 implementations. Anyway, without these, that leaves <object>, <iframe> and the non-standard <embed>.

Of the remaining candidates, <object> is the most reasonable solution because it allows fallback content to be displayed if the user agent does not support SVG rendering. This is important - if a user doesn't have a browser that supports SVG, they may not want to download Adobe's plugin, which means they can't see your content unless you can provide fallback content in terms of PNG or whatever.

However, in my experience ASV seems to have inconsistent results with <object>, while I have found that <embed> works reliably in ASV. Firefox and Opera do not like <embed> and seem to work reliably with <object>. Frustration! My experience with <iframe> is limited because I want to use <object>, but I do not know of any issues with it.

My solution to this dilemma was to provide <object> for non-IE browsers and <embed> in IE browsers. I had done this using some JavaScript that transforms <object> elements into <embed> elements if IE is used and ASV is installed. You can see the JS here.

The problem with this script is that it needs to be run when the page loads, which causes some delay in rendering and turns out to ultimately be unnecessary. Stefan Oskamp gave me the tip of using IE conditional comments. With this technique you can serve an <embed> to IE and an <object> to every other browser:

One final point: Both Firefox and Opera provide a way to inline SVG with XHTML. This means that you can have an XHTML document with SVG elements inside it (not referenced to another document). The issue is that IE does not support XHTML or mixed XML grammars at this time (and is unlikely to for awhile). If you'd like to constrain your audience to just Firefox and Opera users, feel free to use XHTML with SVG content and keep your eye on the CDF Working Group.

How To Link Between SVG and HTML Documents [TOC]

The next issue I found was in managing hyperlinks across SVG and its parent HTML document.

Update 2007-01-17: In fairness, I should note that Opera 9 and Firefox 2 have fixed numerous issues with linking so that now a semi-sane solution is quite deployable. That means another year or two from now (when Opera 8 and Firefox 1.5 have faded from view), I can update my website. Such is the life of the web developer...

HTML provides support for hyperlinking using the <a> element. This element allows you to specify the target "frame" of the new link. In default cases, this means when you click on a link, the enclosing HTML frame gets replaced by the contents at the new link. If you're using HTML frames and you wish to replace the entire page (i.e. the "top" frame) you need to specify the target attribute to be equal to "_top".

SVG also provides support for hyperlinking within an SVG document using a similar <a> element. Unfortunately, the default targetting behavior when a link is accessed (clicked) is not consistent across implementations.

Let's say we have the following four files.

testcc.html:

twolinks.svg:

testtarget1.html:

testtarget2.html:

If you click on testcc.html you will see two paragraphs surrounding the SVG document (which contains two links). When you click on a SVG link in IE+ASV, the entire web page will be switched to the corresponding testtarget HTML document. If you click on a SVG link in Firefox or in Opera 8.x, only the SVG document will be switched out for the appropriate testtarget HTML document (in other words if you clicked on "Link 1", you'd have testtarget1.html embedded within testcc.html). Opera 9 TP actually switches this behavior to follow IE's approach.

I'm not clear on what the correct behavior is here - maybe it is unspecified, but I tend to side with Firefox and Opera 8.51 on this one. The SVG link is with respect to the document in which it is located (i.e. twolinks.svg) and not within a parent document. Behavior should be consistent whether the SVG document is linked to directly or referenced from within a containing HTML document.

Anyway, differences aside, the question becomes: How do I get consistent behavior?

For my experience, I actually WANTED an SVG link to result in the entire web page being switched for its target. In this respect, it should have been as simple as adding target="_top" to the svg:a elements as specified here.

Unfortunately, this does not work with either Firefox or Opera 8.x. What I did next was add in a JavaScript hack to get Firefox to work:

Now it works properly in Firefox 1.5, but since Opera 8.x does not support JS scripting of the SVG DOM, the above hack does not work. What I resorted to then was a hack that I'm not proud of. Basically I put the following "frame-busting" JavaScript at the top of all my HTML pages by using some PHP templating:

This works in Opera 8.x, but only partially. You still see the target document load up in the <object> frame and then almost immediately the entire page switches to the target document. What a fugly hack! Unfortunately, Opera 9 TP1 "fixes" this by resorting to switching the entire enclosing document for the target one, even if target is not specified. I will be in contact with Opera developers for them to fix this as I consider it a bug (i.e. they should support the standard specification).

It should be noted that the Compound Document Framework seeks to address issues like this and may be of interest.

How To Write Compliant SVG [TOC]

An unfortunate side effect of having Adobe's SVG Viewer become the defacto implementation is that ASV accepts noncompliant SVG documents. The biggest "mistake" I've seen is that ASV does not require XML namespaces to be bound.

Firefox requires the SVG namespace to be mentioned (bound) in the <svg> element. On the other hand, Opera's native implementation does not require this, meaning that Firefox may be right, but they are in the minority. Jonathan Watt (of the Firefox SVG team) has provided some great authoring guidelines that describe this and other issues for bringing SVG documents into compliancy.

Opera developers should follow Firefox's lead here and enforce stricter compliancy as well, otherwise the web will forever be littered with noncompliant SVG documents. We need to fix developer habits now. As XML grammars become further integrated, namespaces become a very important issue.

Working Around Adobe SVG Viewer [TOC]

I'm writing this section because I found these couple "gotchas" and I know others have stumbled across them as well. The Adobe SVG Viewer (ASV) actually uses a very old version of the Mozilla scripting engine, and there are a couple issues with this to keep in mind when writing SVG for ASV :

Beware Of The NodeList [TOC]

Some DOM methods like getElementsByTagName() return NodeList objects. A NodeList object is a collection of live DOM nodes that you can then work with. The JavaScript bindings state that NodeList objects can be operated on using the array-index operators (square-brackets) to get at an individual node. As a result, you'll often want to write code like this:

Unfortunately this won't work in ASV because ASV does not support using square-brackets on NodeList objects. If you want code that works in Firefox, Opera and ASV, you should rewrite your code using the NodeList item() method instead like so:

The above code will work in all fully-DOM compliant user agents as well as ASV.

setTimeout and setInterval [TOC]

JavaScript uses setTimeout() and setInterval() methods as ways to delay execution of code or repeatedly execute code. You will want to write code like this:

You can even do:

Unfortunately, ASV does not like this - ASV only expects a string as the first argument in the setTimeout() and setInterval() functions. This string will then be eval'ed and executed, so it's pretty close to the same thing, but not quite. So to make your code work in Firefox, Opera and ASV you should rewrite your code like this: