I’m writing an article on using SVG for site decoration and backgrounds. Since SVG is now allowed in HTML via HTML5, it seemed a good time to introduce people to the concept. Especially since the nightly build of Firefox 3.7 has a configuration option (“about:configure”) where you can enable HTML5.
To test the new option in the Firefox nightly, I created a simple file, with a SVG red circle that can be resized with JavaScript. (HTML5 version and XHTML version).
Clicking on the circle will resize it, but also throws up some alerts outputting information about metadata in the element, including namespace, prefix, and element tag name. I wanted to see how Firefox parsed the SVG via HTML, as compared to XHTML. After all, it’s not unusual for SVG files to have namespaced entities in them, for metadata (Creative Commons RDF/XML), or even placed by a tool (Inkscape).
The results are about what I expected. The namespace, prefix, and tag element name all displayed according to their namespace goodness in XHTML, but the namespace didn’t work with the HTML parsing.
To me, this isn’t a showstopper. People who have been working with the DOM and JavaScript have had to deal with differences through the years, such as event handling differences between IE and the rest of the browser world. You just check to see MIME type of page, and either expect to look for the localname as a mashup between prefix and local name, or it’s handled properly.
It’s a little *challenging because prefixes aren’t always going to be the same. However, for the most part, if you need to access the data, you can either control the prefix used, or you can work through the differences without having to resort to rocket science. I rather expect both Dojo and jQuery to incorporate this functionality, once HTML5 gets wider use.
I also have been trying the new SVGWeb product from Google, and fine folks like Brad Neuberg, which enables SVG in HTML for all browsers, including IE. It does this by incorporating a JavaScript library that implements most of the SVG in Flash. Since Flash is pretty much ubiquitous, folks won’t have to install something new for the page to work.
I’ve used SVGWeb to manage the background image for The SVG Feed, which is now formatted as HTML5, and served as HTML. It works nicely in Safari, Opera, Firefox, and even SVG-challenged Chrome, but IE has a problem. Unfortunately, height and width are handled differently with IE as compared to the other browsers, so the values are coming up null in IE. However, Brad has added this as a bug, and I expect this page will work in the next iteration of the product.
Now, there are some differences between SVG parsed by an HTML5-enabled browser, and using SVGWeb. My earlier example embedded SVG directly in the page, but SVGWeb expects an inline SVG element to be enclosed in a script tag:
<script script type="image/svg+xml"> <svg... </script>
Embedded SVG in a script tag won’t work if you’re only dependent on HTML5 parsers. However, SVGWeb also works with HTML5 parsers, so you’re set, either way.
Until all browsers support SVG, in HTML or XHTML, SVGWeb provides the first real breakthrough in using SVG on the web. And here you thought that SVG was only good for **Scrapbooking.
*It’s a little more challenging for server-side applications parsing the web page, but again, the differences aren’t insurmountable.
**The background SVG I’m using for my site originated as a scrapbook pattern for the cutting machine, Cricut.
