SVG is such a superior format for icons, it scales perfectly, is very efficient size-wise. The only annoyance is getting them inline so that they can be styled with CSS.
Compared to raster graphics, yes. Compared to other vector formats like SWF, no.
Here's a real world example. Two SVG icons from the same github repo:
https://camo.githubusercontent.com/e448a75c4115d60100a0a2b29...
https://camo.githubusercontent.com/d9522bd55c6c95a14f51f8e7c...
While they are in the exact same repo/collection, they have clashing gradient names. If you grabbed those and put them both inline, in the same page, it wouldn't work.
It also doesn't play well with dynamic content where you have the cache headers set to not allow local browser caching, as it causes a second request.
Would have been nice if there was an additional way to reference the gradients, maybe css (not using a url fragment that is...defining the gradient itself).
Ah, I see. Yes, you're right. Additionally, the HTML5 spec is written such that FuncIRIs won't work in about:blank, making it impossible to quickly test svg gradients or patterns in Firefox. (But it works in Chromium for some reason, which is nice.)
I think the Snap.svg framework gets this right-- it allows the user to specify the gradient with a single string, much like the "d" path data.
Seems like the only way around that is to take a hash of the gradient.innerHTML and use that as the id of the gradient. Of course that increases the size of the svg file, but as you point out it's necessary (comically so, given all the complexity of xml namespaces don't prevent this clash).
... in which case the same gradient in two different inline svgs would create a duplicate id.
Too bad CSS gradients don't work in svg shapes.
As an alternative image format to things like PNG? There aren't many, if it's an image that lends itself to a vector format in the first place. SVGs have been widely supported for some time, often have significant file size benefits as we see here, and scale cleanly to different screen resolutions. You have to go back to versions of IE that even the likes of Microsoft and Google won't support any more or to very old mobile devices to start running into general compatibility problems.
One thing to be aware of is that you are effectively programming your graphics if you're using SVG, not just recording the image itself. If you start playing with the more powerful features, particularly using non-trivial filters, you might occasionally run into issues in the rendering code that turns your program into an on-screen image. Depending on how much of that code is in the browser itself and how much is delegated to the underlying OS/graphics drivers for acceleration, that can cause problems including slow display of images, distortion so the rendered image doesn't look right, or in extreme cases even hanging the browser or graphics driver if you're unlucky enough to trigger some underlying bug (which is obviously a rare result, but I have personally seen it happen in my own development work). For the kinds of very simple SVGs we're looking at here, I can't imagine any of these potential problems being a serious risk, though.
Yes, you probably newer encounter them, but they are still there.