IE 10 (and to a lesser extent, 11) has really wonky support. In a self-contained SVG, it's fine. Once you need it to scale a certain way, you'll find things get weird.
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.
If you deploy a Remote Desktop or Citrix Server based environment - which Microsoft/Citrix continue to push heavily to enterprises - well Microsoft set Windows 2016 Server as the flagship server OS and then for some reason didn't include Edge. Just IE11.
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.
The icon with the two white dots is far from optimal still:
The grouping is unneccessary. style="fill:#FFFFFF" can be replaced by fill="#FFF". There are useless newlines. height="100%" width="100%" can be replaced by height="512" width="512"
That's a good point! As I say in the readme, I left in the newlines to make them more readable - but I'd certainly take a PR for the colours and grouping.
As for the heights - will that make a difference if the image is scaled?
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.
Gradient fills are something of a pain as well if trying to do them inline or sprited. Though I guess HTTP/2 makes additional downloads less of an issue.
It's not hard to to do it manually for a single svg, but having to track the namespace and match them back to the right svg element via url fragments is cumbersome in a real world site. Many svg creation tools autoname the gradient and then you have to hand edit it so that it's unique. Or you end up with two gradients called "SVGID_AUTOGENERATED_1" in the same html file.
Here's a real world example. Two SVG icons from the same github repo:
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).
> It's not hard to to do it manually for a single svg, but having to track the namespace and match them back to the right svg element via url fragments is cumbersome in a real world site.
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.
> 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.
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).
I am curious to hear, is there any reason not to use them?
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.
The only serious argument I've heard against them is that it makes life easier for people who want to reverse engineer your graphics. But, frankly, I'm switching as much of my stuff over to them as possible.
This is really great. As someone who has done quite a few size-sensitive projects/experiments, have you considered providing them in a small website? So artists can contribute with more icons and developers who want to use them can modify them when downloading (border radius, background, etc). I could throw a quick prototype if that sounds good.
whenever i need a figure, instead of opening paint I hand code a SVG. It takes a bit longer then painting. But is more acurate. its basically just xml and math. maybe a bit of css for styling.
i would like to see less bitmaps and more SVG especially by web devs.
Somehow unrelated, many people showed how at low resolution vector graphics rendering alter the perceptual nature of icons compared to bitmaps (crafted by human eyes for human eyes). So I believed the author made vector shapes, with the goal of very small "ascii art" flavor baked in.
Yes. You can't beat PNG in low resolution, because it's hard to make SVG pixel-prefect on all resolutions. But on modern devices, with high DPI - it's not a problem. And you will get a high size reduction (but with some runtime cost).
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.
I might have to add my Instagram SVG to this collection. Mine is 4 lines of SVG with a def for the the gradients. I started with the 1.8 Mb file provided by the Instagram brand guidelines and set to work.
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!
These aren't just for sites. Android apps quite often contain multiple images in different resolutions. Your phone's memory is being eaten away by developers who don't care about efficiency.
Even at Amazon S3 prices and a million downloads the cost savings of using the SVG for the Github icon is only $1.60 per month. If it took an artist an hour to make at $30 an hour it would take a year and a half to break even.
keep in mind that making the size smaller also make your website more light and faster, same thing for android/ios app, where the fact that this icon are in svg format make them scalable at different resolution, screensize and dpi.
Image are usualy the main reason to oversize app and webpage.
That's a restatement of the hacker ethos. I.e., why waste 10 minutes on a boring one-off solution when you can spend 1 month building a library that reduces all future boring one-off solutions to 1 minute?
I think it wouldn't matter in either case, really big svg would be only marginally bigger in size. It would be a different case for png and jpegs, not so much with svg.
Especially since SVGs are not hinted for small sizes (AFAIK).
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.
You can use responsive CSS to switch out different shapes in an SVG to make them display better for a range of sizes. There's no tooling to automate this so it basically requires hand editing.
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.