As it happened, within only the span of a few days, Jeff Schiller had taken on the challenge and made good progress towards those pretty SVGs. Being a somewhat seasoned SVG hacker, he even opted to introduce interactivity to the graph too, scripting it to show not only a static snapshot of a day's stats, but rather the entire history of his blog's visitors.
SVG, like HTML and presumably many other W3C standards to come too, ties in very neatly with ecmascript; embedding code is just as easy as javascript in HTML in the web world. Arguably even somewhat easier, as there is less legacy pre-DOM days baggage to bother about, SVG not having been with us since the dawn of the web.
Anyway, Schiller had already given the matter some thought previously, so I presume he was really waiting for the right inspiration to get going, and from what I gathered of his comments on the post, he was going to leave it there, as it was.
Wanting to see how far off the SVG front (in released browsers) is from being able to cope with making something as pretty as the originals, I picked up the ball and played some more with the code.
As it turns out, we are pretty close; it's really just some filters left, to add gaussian blur shadows for text and pies, perhaps some
<textPath>
to bend the text around the edge of the circle perimeter, and of course much, much better font rendering. Except that, we are more or less already there. I actually thought it was still farther off than that, but the good browser developer people have been busy.Of course, picking the right font is also of utmost importance, but as fonts go, I am very unseasoned myself, so I have not even tried here. Having said font on the client side is also an issue I don't think SVG addresses yet, but I presume some decent set of fallback font specifications might render more or less as intended too.
The data featured in my graph is actually what my traffic looks like, since I started tracking this blog with Google Analytics, formerly (and still, by some) known as the Urchin tracker. It was a bit of work bending out the data from the view and massaging it to sum up <1% slices into bigger chunks, summing up sibling minor versions and the occasional really exotic browser into categories, but most of it could hopefully be automated, given some work. I have not dared experiment too much yet, as I don't want to trip a lock-down in sector four.
I'm not saying that applies to all Google sites yet, nor that it doesn't, but as I haven't dived particularly deep into the fine print of the Analytics terms of service I have so far opted to be cautious.
The really great thing not yet mentioned in this story, is the file sizes of these pretty things. The PNG thumbnails I opted to put in this post (as there is still quirks and issues to circumvent when inlining SVG images into page content, Jeff reports) each weigh in around 40 kilobytes, or 70 for Jeff's dual graph. My SVG and its companion external javascript file weigh in at two plus seven kilobytes, or together about a fourth of the size of the thumbnail, and they scale very nicely to any size, not just the 200 pixels high versions seen here. Jeff's version (presently) is a hundred kilobytes, but also sports not the data for one, but for a hundred and seventy graphs you can instantly switch among, at the click of a mouse button in the left graph, or arrowing back and forth via the keyboard.
For comparison, two kilobytes is roughly the size of the tiny flag images at the top right of my blog for machine translation to other languages (very forcefully frowned upon by my girlfriend, by the way, translator by trade) -- so not only can we expect to see much prettier graphics once SVG imagery becomes mainstream on the web, but we will also get much speedier delivery of them. And more bandwidth to spare for the video blogs to swallow it all up again.
Good times ahead, people.