Simple SVG in HTML test page

http://philarcher.org/diary/svgtest/

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 is to use the object element and define the SVG file
using the src attribute, thus:





alt : Your browser has no SVG support. Please install
plugin (for Internet Explorer) or use ,  or  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:

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

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?
Well, yes…








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


However this is only true if the page is served with the (correct) application/xhtml+xml Content-type HTTP header.
If you just serve text/html then even the standards-complaint browsers will not display the SVG.

Using an iframe
The remaining possible method is to use an iframe element.




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 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, within Moodle we're likely to use the embed element since:

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

Outside Moodle, the <object> element is the way to go or, if served with the correct Content-type, include SVG directly in XHTML.
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…