Tiny Social Icons – Miniscule SVG versions of social app logos
github.com
github.com
SVG browser support: http://caniuse.com/#search=svg
Pretty much everything of any significance supports it except IE 8 which has 0.3% market share and is no longer supported by Microsoft.
IE 10 basically dropped off the face of the earth, but 11 is stubbornly hanging on. Still, if you're optimizing the size of SVG bytes for the benefit of these browsers, you're likely to add that weight right back in with all the IE-specific CSS you're likely to add in.
This decision still makes IE11 Microsoft's recommended browser for those deployments, which sets a course for certain enterprises to prefer it over Edge for new deployments.
As for the heights - will that make a difference if the image is scaled?
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.
Compared to raster graphics, yes. Compared to other vector formats like SWF, no.
When I was putting together a handout for work (https://twitter.com/StanfordCompute/status/85047937335846502...), I wanted to get vectors of the four logos that appear on the bottom of the front side (of course I already had a vector of our logo).
Both SLAC and XSEDE had vectors available on their web site (IIRC, as EPS files). For the Open Science Grid, I had to reach out to someone, but that was easily done. Same for ICME.
I guess the corporate world is different: I'm sure they have vectors (likely as .ai files, which can be exported easily enough), but don't want to make them available. That's too bad.
Inline SVG is the way to go, however, if you have a large SVG stylesheet then some hacks are needed to load it as a cached image and get the thing inline on the page. Greatest fun since LEGO though!
Then maybe we shouldn't use complex vector graphics, and instead use nice and simple uncompressed raster graphics. /s
I'm not even sure if SVGs are rendered equally at the pixel level on all render engines. This is important for small images.
This is true, but the situation is no different with the main raster image formats either, and the solutions are the same either way.
I'm not even sure if SVGs are rendered equally at the pixel level on all render engines.
They certainly aren't. You're programming a graphic and then whatever rendering stack is available on the user's device will render it as an on-screen image. The quality of that render, for example when it comes to gradients or anti-aliasing, is environment-dependent.