Simple SVG in HTML test page

I've created this page as part of the preparation for an upcoming course on SVG that we're running at W3C. We're running the course as part of the OMWeb project, the aim being to increase the number of developers able to create rich content. Unlike the Mobile Web Best Practices course, I'm not actually doing the teaching this time - that's down to David Dailey (who is literally writing the book on the topic!). However, I'm going to be doing the course admin and generally taking care of things from W3C's perspective.

The choice of SVG for the course is due largely to the very welcome news that IE 9 will support it. This means that soon all the major browsers will include native support for this flexible, powerful method of adding graphics to Web content — graphics that can be animated using scripting and that will be indexed by Google.

As with begining to use HTML5 to code pages, the problem is backwards compatibility, particularly with IE. Version 9 will only work on Windows Vista upwards and, given that a depressingly large number of people are still using IE6, we can't expect an overnight revolution.

This page sets out the various methods of including SVG in HTML and offers comments on each one.

Please note that the page itself is written in XHTML Strict 1.0. This is the markup used in Moodle which is the platform we're using to deliver the course. Some of the solutions here cause validation errors since neither embed nor iframe are defined in XHTML 1.0 Strict.

The SVG used in all tests below produces a pale blue square with the words "Click anywhere" near the top. If you do click in the square an ellipse will appear centred on your mouse click.

Using object

The preferred method seems to be to use the object element and define the SVG file using the src attribute, thus:

alt : Your browser has no SVG support. Please install Adobe SVG Viewer plugin (for Internet Explorer) or use Firefox, Opera or Safari instead.
<object id="E" type="image/svg+xml" data="http://srufaculty.sru.edu/david.dailey/svg/ovals.svg" width="320" height="240">
alt : Your browser has no SVG support. Please install <a
href="http://www.adobe.com/svg/viewer/install/">Adobe SVG Viewer</a>
plugin (for Internet Explorer) or use <a
href="http://www.getfirefox.com/">Firefox</a>, <a
href="http://www.opera.com/">Opera</a> or <a
href="http://www.apple.com/safari/download/">Safari</a> instead.
</object>

This works well in all the SVG-supporting browsers. In Internet Explorer, even with the Adobe plugin installed, you see the fall back message encouraging you to either install the plugin or use a different browser.

Cross-domain

Notice that in this example the SVG file itself is hosted on the Slippery Rock University's server (at http://srufaculty.sru.edu/david.dailey/svg/ovals.svg). If you use IE with the Adobe plugin, you will see a warning message that the page is accessing information not under its control. This warning can be avoided by serving the SVG from the same domain as the HTML, however, IE users still see the fallback message.

Incidentally, don't be tempted to add in a param element i.e.

<param name="src" value="http://srufaculty.sru.edu/david.dailey/svg/ovals.svg" />

If you do that then IE users who have the plugin installed won't see the SVG, rather just an off-white square where the SVG should be but without the fallback text.

embedding remote SVG content

<embed type="image/svg+xml" src="http://srufaculty.sru.edu/david.dailey/svg/ovals.svg" />

Again, this works in all the SVG-supporting browsers but not IE, even with Adobe's plugin.

embedding local SVG content

<embed type="image/svg+xml" src="ovals.svg" />

Using embed to include an SVG file hosted on the same domain as the HTML page produces a better result than above in that it works in the IE/Adobe plugin combination so this looks like a good solution. However, there are two drawbacks:

  1. There is no way to include fallback text for IE users without the plugin (noembed doesn't help us since IE supports embed);
  2. embed is not defined in XHTML so any page that uses it is invalid.

On the plus side, it seems to work well and is as easy to implement as img elements so it's attractive to authors.

Writing SVG directly into the document

Since we're writing this page in XHTML, it should be possible to declare the appropriate namespace and include SVG directly in the document, no?

Sadly, no.

 
<svg xmlns="https://www.w3.org/2000/svg">
<circle r="50"/>
</svg>

No browser displays any SVG here sadly.

Using an iframe

The remaining possible method is to use an iframe element.

<iframe src="http://srufaculty.sru.edu/david.dailey/svg/ovals.svg">
Your browser has no SVG support. Please install <a
href="http://www.adobe.com/svg/viewer/install/">Adobe SVG Viewer</a>
plugin (for Internet Explorer) or use <a
href="http://www.getfirefox.com/">Firefox</a>, <a
href="http://www.opera.com/">Opera</a> or <a
href="http://www.apple.com/safari/download/">Safari</a> instead.</iframe>

This works after a fashion, in that if you have the plugin installed in IE, the SVG is displayed, even if hosted on a different domain. However, we hit the same problems we saw with embed in that there's no way to display fallback text (since IE does support iframe) and iframe is not defined for XHTML 1.0 strict.

Using the file directly from http://srufaculty.sru.edu/david.dailey/svg/ovals.svg not only prompts the cross domain warning but also triggers another (presumably related) error message in the Adobe plugin (permission denied line: 15, column: 2). For this reason I've used a local copy of the ovals.svg file here.

A final oddity is that Moodle doesn't allow you to put any markup between <iframe> and </iframe> — it replaces angle brackets with their HTML equivalents (&lt; etc.). This is nothing to do with browser support for SVG but is relevant to the the current discourse.

Conclusion

The Adobe plugin offers a way for users of IE to access standalone SVG content that is either delivered directly to the browser or included within an HTML page using embed, so long as it's hosted on the same domian as that page. However you proceed you need to think carefully about what IE users will see.

Speaking personally, I think it's important to provide fallback content for IE users. I'm also someone that likes to ensure my (X)HTML is valid. For those reasons I favour the object element, perhaps using a static image as the fallback content. In this scenario, IE users will probably get a poorer experience than users of other browsers (obviously so if the SVG is animated).

However, for the purpose of the course we're likely to use the embed element since:

  1. Within the context of the course it is obvious that participants must use a browser that supports SVG;
  2. it's a little easier to write and maintain pages using embed, which is very similar to using img elements.

Note - for this exercise I have not considered more advanced features of SVG such as support for SMIL, scripts that interact with both the markup and the SVG etc. Such considerations may well lead to different conclusions. Ultimately, Occam's Razor might suggest one asks IE users to change to a browser that supports SVG…

Home
Diary