I was having a look at the SVG version from the feed icons site and I was surprised how well it rendered.
Interestingly the SVG file is just 1.2kb! Gzipped, it’s 545bytes. A PNG 32×32 pixel version is 1.5kb and the 10×10 is 469 bytes. I wonder how the PNG format’s size grows with the pixel size. SVG‘s size won’t grow, though that’s a lie; surely memory whilst rendering the SVG will grow at some rate whilst zooming into it?
I was thinking SVG would be great for mobiles, but it is hard to argue the case. For example, rendering the SVG is surely harder than to decode a bitmap image. Also, what is the point of scaling up into an SVG graphic (on a mobile) anyway?
Perhaps we are still better with a JPEG2000 type approach. as bitmaps are far more common than vector graphics. Sadly, JPEG2000 is heavily patented. How frustrating. 
Spent an hour or two looking at SVG and embedding them into Web pages.
I worked from Ian Hickson’s Webstats and I didn’t get very far. I grabbed another svg from somewhere else, and it wouldn’t render without a ?xml-stylesheet def. Which I think is a little weird.
I don’t like all these pixel definitions. It’s so not easy to simply say this bar is 40% big and another is 60%. Instead it is drowned in this x, y placement cruft.
Perhaps canvas is the answer. I’m unsure how the spec has been implemented in Firefox. If I understand canvas correctly, then these graphs/graphics would be generated programatically with Javascript. Which sounds kinda sucky.
SVG looks like it will take a while. For graphs et al, I rely on R and just export to PNG or something else that doesn’t scale.