Lots of interesting discussion about SVG in browsers. Here’s a roundup of my favorites, along with my thoughts:
- To Joshua, if MSIE has a kick-ass graphics engine, and there is a plentiful source of data out there on the web to drive it, why on gods green earth would Microsoft willfully chose to ignore it? Someday, I would love to report that IE12 wipes the floor with other browsers on this test. On both the left and right hand sides of the page.
- To Doug, great post. Makes a lot of sense when talking about new vocabularies. I’m a bit leery about central registration. But specifically about SVG, it is an existing vocabulary. You can find plenty of examples on Wikipedia and other places. Ideally someday people could be able to view-source/copy/paste said examples onto their MySpace pages.
- To Anne: that’s closest to what I would like to see. My biggest problem with the WHATWG and the existing W3C HTML working group can be best expressed by comparing it against Atom's roadmap. There are four principles listed there. The WHATWG consistently achieves three out of four. I’d like to see HTML5 cater to the long tail developer as well as the big browser vendors. XHTML5 meets all four, but is as an unforgiving and inhospitable environment that it might as well be the moon for most people.
But all in all, momentum is building towards supporting SVG in HTML5, and that makes me happy. It is clear that whatever form it takes won’t satisfy everybody. I’d still prefer that HTML5 support distributed extensibility, but meanwhile, let me toss out the following; merely in the spirit of brainstorming:
<!doctype html> <title>SVG in text/html</title> <p> A green circle: <script type="image/svg+xml"> <circle r="50" cx="50" cy="50" fill="green"/> </script> </p>
As I said, no solution will satisfy everybody, and the above clearly won’t support nested scripts. It also requires copy/pasters to skip over the XML prolog, DOCType, and perhaps even the outermost <svg> tag itself. None of these issues need apply to
<script src="…"></script>. Ideally, the end result of such a “script” would be nearly indistinguishable from the DOM nodes that standards-compliant browsers produce for inline SVG in XHTML today.
Update: Michael Day suggests
<style> instead. If the HTML5 working group will agree to stop hoisting such elements into the
<head> section of the DOM, that would work too.