I have been using https://simpleicons.org for a while now. It is super light and looks great. License is CC0. Although I prefer inlining the icons over using <img> tags.
The point of CC0 is that in countries (like the US) with the concept of releasing works into the public domain—relinquishing all copyright claims on the work, that's what you are doing with CC0.
In countries where you can't legally release works into the public domain, CC0 is a license that tries to do as much as it can through a license in those countries.
As I understand it, "code licenses" like MIT and "content licenses" like Creative Commons have slightly different intended areas of application, and you shouldn't mix them. E.g. "linking" means different things for code and images.
So you'd use e.g. CC0 for an icon set together with MIT license for some javascript/whatnot code that goes with your icons.
CC0 can be used for source code. For example, the FSF lists it as a GPL-compatible free software license and states: "If you want to release your work to the public domain, we recommend you use CC0."
CC0 reverts to "Public Domain" in countries/jurisdictions where this is a thing. When this is not possibly it tries to legally define the closest thing possible.
"Public Domain" in particular means that the author distances themselves entirely from the work and all the rights pertaining to it. You don't need to credit them, I believe you could even claim it as your own (that'd be ethically dishonest IMHO, but legally fine). Second, the author also distances themselves from any responsibilities regarding this work (such as accuracy, fitness for any purpose or safety).
From what I've learned about copyright and IP law (extracurricular course next to my CS education, highly recommend if you get the opportunity) and reading, it's especially these last two points that are sometimes (in some jurisdictions/countries) difficult to get rid of or distance yourself from, as an creator. They don't always allow it. For instance (someone correct me if I remember this wrong), in the Netherlands a creator cannot fully distance themselves from the right to claim "I created this". Meaning that ghost-writing is contractually not possible and relies on the honour of the ghost-writer to keep their mouth shut. It's a bit of a vague thing and we didn't delve too deeply into that example. It's generally a minor thing.
Same goes for whether a creator can ever fully distance themselves from any responsibilities over the work they created. I can imagine some jurisdictions may not allow that either. I'm not sure how that works in NL (was not covered in the course).
Anyway in this sense, CC0 is a lot like the WTFPL without the profanity, I guess :)
Just last night I was playing with Primitive [0], which tries to reproduce photographic images by building up layers of shapes. I found this via SQIP [1], was discussed on HN last week.
I haven't tried this with line art like icons or logos. I usually just hand-optimize simple ones, then run them through svgo [2].
In case anyone else was suspicious of the 20k file size for a 512x512 PNG with essentially two colors - it's way off. I dropped it into Photoshop and exported as PNG and it spit out an identical file that weighs in at 6k.
And if you run it through https://tinypng.com it should get down even smaller. PNG compresses surprisingly well when it’s basically two colors + alpha.
TinyPNG tends to use fewer colors. But its compressor is pretty suboptimal. I could reduce the image further by 15.4% with the tool I'm making (http://getoptimage.com).
A lot of these are logos that I had assumed to be registered trademarks. As such, they would only be usable under the terms of a licensing agreement with the owning company, terms which I had assumed would be pretty anal-retentive regarding the exact details of the representation. IIRC, Facebook has a specific art package with specific image files that one is suppose to use, and no other.
On the one hand, this is pretty common knowledge. On the other hand, none of the responses so far have brought it up, and the logo website itself seems to think that the cited sources can license the use of the artwork in question. I do not quite know what to make of this.
What you have said is simultaneously completely true and totally pointless.
Yeah, we all know that brands have tediously anal rules about usage of their logos in particular. In practice, so long as you aren’t obviously abusing it, nobody is going to care. Have you seen some of the stuff what people do with social media logos??
Just to pick on the one I know best, the Y Combinator logo is way off. The corners shouldn't be rounded, and the Y is too big and its top branches are too thick.
Amazing! With SVG being supported on all browsers you should care about today, it obsoletes icon fonts, which require the entire icon set to be downloaded.
Anyone know of a FontAwesome-like project, ideally with a CDN, that serves SVG icons like Font Awesome has so including them in a website is easy and compact?
Also, the new "Font Awesome Pro" comes with all icons as SVG out of the box - https://fontawesome.com/
Last, one annoyance (in the midst of many benefits) of using SVG instead of fonts as icons is that you can't change their color via CSS if you're including them via <code>img src='file.svg'</code>
So I use BoxySVG. Boxy is to Illustrator as Acorn or Pixelmator are to Photoshop. A tightly focused editor that lets you do simple things (like edit colors) very rapidly and doesn't bog you down with a ton of extraneous features.
So the distinction is inlining SVGs vs referring to them like you would a png with an img src=filepath.svg|png in your HTML.
It's handy to just treat them as you would images, but you lose some flexibility wrt being able to manipulate them via CSS b/c the browser now "thinks" of them like an image.
This SO post has a clever workaround (with I'm sure more caveats wrt performance, etc) that will auto-inline your svgs that you need to manipulate so you can get a best of both worlds type situation going.
As a designer I always recommend https://feathericons.com/ as an alternative to font awesome. All SVG, all with uniform sizing and a pretty diverse selection - not as diverse as FA, but still. Very pretty and not as widely adopted as FA.
Yes! Loading many sites without width/height set on mobile connections display a horrible jitter with logos and social icons polluting the entire screen initially.
In the case here with the Twitter logo, lack of height attribute causes the logo to look squashed on some oldish browsers. I imagine the addition of height would fix this.
At what point does using a vector SVG is worse than raster image? Level of image complexit, requiring a ton of path elements?
the Twitter logo can be create in basically 2 path elements.
What if my logo is much more complex? Is there a threshold at the complexity of my image results in an SVG payload > than a properly compressed raster image?
For tiny images like icons, where intricacies are hard to see, it's likely they will almost always be better in svg.
Logos especially are generally by nature clean and simple to be able to quickly communicate brand through different mediums.
From a practical sense, I'd be hard pressed to find a real logo/icon that wasn't better in SVG. Theoretically, of course there are limits, but the rule of thumb is strong: always use svg for logos and icons.
Gradients are sometimes translated strangely--I used illustrator to cover some .eps graphics to svg that were given to me by some company and the gradients got funky.
That's my issue with the svg reflex, re-rendering complex geometry is more demanding than byte copy. That said https://edent.github.io/SuperTinyIcons/tiny/twitter.svg is really really really simple. I had no idea svg.fill could encode such things, and expected a bad mix of overlapping ovals to create the illustration.
Yes, you can make an image that compresses to a smaller raster image vs. SVG, and complexity is a good way to do that. Especially possible if your image/logo isn’t just solid colors, but contains gradients or textures.
I would guess, though, that if you make a logo that is larger as an SVG than a compressed raster, you’ve probably made a bad logo. Logos should be simple.
Agreed. Simple but important things to also consider with Logos include "What does it look like if printed in black and white?" It's a bit outdated advice in some regards, based as much on letter headers, fax machines, and news print adverts, as anything else. You'll notice that almost all memorable logos work really well in black and white, though.
Black and white is a good exercise in general, eg also to check whether divers colourblind people will be ok. Or when you want to carve your logo into metal or wood etc.
Is there a way to quantify simplicity in terms of SVG? Can we say number of points & number of paths? What other constructs can be used to measure complexity?
There isn't really. Any of those things could be used as proxies (plus file size, number of XML elements, rendering time, and more), but the thing we are really interested in is subjective anyway.
File size after rendering to bitmap and lossy compression, like JPEG, might actually be one of the best quantitative proxies for simplicity, because lossy compression algorithms are designed to compress visual data that's interesting to humans well. Maybe an interesting experiment: take a whole bunch of logos and/or other images, let people rate them on a Likert scale or something on simplicity, and see if there's a correlation with JPEG file size.
I draw comics in Illustrator, and I have created files that are larger than the corresponding 300dpi TIFF. I think the first page in http://egypt.urnash.com/rita/chapter/viii/ is one of them, that dense setting at the bottom is super complicated.
(And it's a TON larger if I save the file as a pdf, Illustrator is doing a lot of high level abstraction to make this file smaller, that I’m not sure if SVG can handle.)
They aren't all under 1KB, but there a few repos on GitHub hosting all of the Font Awesome icons as SVG.
Also, if you can avoid it, don't use <img src… to display SVG images, as the article suggests. By using <svg… directly, you avoid extra requests, you gain the ability to manipulate them directly in the DOM, and to restyle them.
I believe you can define a <symbol> in one inline SVG, then <use> it in another, so that'd be a way to achieve icon reuse. Not sure how good browser support is for that, though - there's probably quirks.
How about keeping readable versions in the repository, along with a script that compresses them? The compressed ones could be automatically served on a separate site.
I'm still a bit sad that Raphaël.js never quite caught on[0]. Same for its successor Snap[1]. I guess the main reason is that SVGs themselves weren't quite popular (and I assume there were also a few bugs) and take a proper illustrator to draw, compared to the ease of fetching JPG assets off the internet.
I bet many of these would be even smaller in SWF, since that's a very efficient (bit-packed, and then compressed) binary format specifically designed for small filesize, as opposed to the textual XML of SVG (although SVG is not really "XML-ish" in the sense that path data is still a list of points, and not one-element-per-point.)
Inkscape is ok. It has serious issues though - pretty terrible performance, confusing UI, still requires X11 on Mac, etc. Probably still the best free SVG editor but I'm not sure I'd go so far as to call it good.
The performance issues are real. Just open a complex SVG, select a few thousand elements with a rubberband selection, and see how everything slows to a crawl as it tries to render the outlines. If that is not slow, try manipulating that selection (e.g. scaling, rotating).
Most of the time, when I run InkScape to edit an existing .SVG, it's because I want to just select and drag a few vector endpoints a bit to one side or the other to make minor tweaks. I'd venture that's true for most users. However, it doesn't seem to be the default behavior. I always have to remember how to get into the right selection mode, because the authors seem to think I most likely want to drag the entire image around. Why I would want to do that, I can't imagine, but that's how it works.
That's a problem for many common actions -- for instance, I normally want to resize the view box to enclose the content tightly before saving an edited file, so why is that common action buried multiple layers deep in the UI? File->Document Properties->Page->Custom size->Resize page to content->Resize page to drawing or selection->Seriously? It's almost easier to do this in a text editor.
Finally, people who write apps that don't remember their previous desktop window size and position, but that instead auto-size themselves to cover the entire screen every time they're launched, should die in a grease fire. Unnecessarily-aggressive hyperbole aside, this kind of obvious forehead-slapping behavior is never good news because it means that the maintainers don't use their own app.
All that aside, InkScape is really a very powerful application that could be a lot harder to use. A great deal of hard work has clearly gone into it, and at the end of the day it is free software, so it's hard to complain without seeming ungracious. If it weren't such a great app, it wouldn't be worth criticizing at all.
I second that. While it definitely isn't on par with Adobe Illustrator regarding some very advanced features, Sketch is so rediculos easy to understand and beautiful to work with that it is nowadays my go to solution for design and layout work that was previously done with Photoshop, Illustrator and InDesign.
The second Twitter icon (which is an SVG) looks very sharp when zoomed in. The table of other icons is a screenshot, not in SVG, so those won't look sharp when zooming in.
I love that SVG survived! It dates back to 1999 and was almost forgotten. When D3js first got started around 2010/2011 I was astonished that SVG support was so good in so many browsers; Mike had been using it even earlier with Protovis and Polymaps. Everything but IE had support as some sort of unnused vestigal thing. And then interactive visualizations started using SVG regularly and now it's vital again.
I wish they had implemented gradients in a way that didn't depend on uri fragments. Not an issue with standalone svg images, but it means you have to manage namespace clashes for inline svg images.
Could you elaborate on the bugs in SVG? Are there any usability issues beyond the bugs? I tried some cursory googling 'why not to use svg', 'svg bugs', etc and didn't really find any common/recurring.
Historically, the SVG-related systems in most browsers haven't seen a lot of love, so it's lagged behind other web technologies. This seems to be getting better — I know Safari just landed a nice 3x performance improvement to one of the SVG filters.
Here's a handful of issues that I still encounter, due to cross-browser differences.
* You can't use the full range of CSS3 colors.
* You can't set certain style properties via CSS (requiring the use of attributes).
* You can't use self-closing tags for certain elements.
* Differing behaviour when you set an attribute to "null" (which is fine, it's just a gotcha)
SVG performance also varies wildly, more so than JS perf, HTML DOM perf, or CSS perf. This seems to correlate with the visual quality of the rendered result — Chrome is the fastest but has excessive smoothing, poor sampling of scaled images, etc; Safari is the slowest but produces the cleanest result.
Someone should build a web service for delivering these social icons. They could place a random selection of 3 or 4 popular social icons on the page, and then, like AdSense the social sites could pay to get an increased number of placements, with a percentage paid back to the site owner.
