
33 Beautiful Open-Source Icon Sets - alokepillai
https://blog.usepastel.com/post/33-beautiful-free-icon-sets
======
ungzd
I'm tired of modern web design. These icons are even not intended to be used
on toolbar buttons, but for silly landing page lists. Landings that are all
the same on every website.

I miss silk icons that were ubiquitous in late 2000s:
[http://www.famfamfam.com/lab/icons/silk/](http://www.famfamfam.com/lab/icons/silk/).
I miss Tango Project icons, although Gnome went off-the-rails in their UI
design. I miss small UI elements, like on freaking Windows 95 desktop, not
optimized for pressing with finger, despite being shown on desktop.

------
qwerty456127
Seems like the meaning of "beautiful" is a little bit too specific today.

~~~
the_pwner224
Agreed. If you're looking for a different style of icons to use in your
application, Tango/GNOME and Breeze are large, complete icon themes.

Tango/GNOME Icons Wikipedia pages (previews many but not all icons):
[https://commons.wikimedia.org/wiki/Tango_icons](https://commons.wikimedia.org/wiki/Tango_icons)
[https://commons.wikimedia.org/wiki/GNOME_Desktop_icons](https://commons.wikimedia.org/wiki/GNOME_Desktop_icons)

Breeze is a bit more 'modern' and would also work well on HiDPI:
[https://github.com/KDE/breeze-icons](https://github.com/KDE/breeze-icons) ;
you would probably want to clone the repo and browse the files manually since
GitHub isn't great for previewing images.

KDE created/used the Oxygen icon theme before Breeze, its style is between
Tango/GNOME and Breeze: [https://github.com/pasnox/oxygen-icons-
png](https://github.com/pasnox/oxygen-icons-png)

------
tom4000
Not all of the presented icon sets are Open-Sourced. Some are, some are free
and for some you have to pay with information about you like your email
address. So the title sounds nice but it is just wrong.

------
keithnz
also, just remember unicode is packed with icons though I find you do have to
check if they render correctly.... but mostly they just work though you may
need to make your font a bit bigger or it may look like

UPDATE: apparently.... HN Isn't unicode
friendly...[https://pasteboard.co/IpxYWjH.png](https://pasteboard.co/IpxYWjH.png)

~~~
danShumway
> you do have to check if they render correctly

In general, avoid using font-based icons to avoid the problem you run into in
your post above. :) SVGs are better in the vast majority of cases where you
have control of markup.

Fonts are unreliable (esp on mobile) -- not enough that you should avoid them,
but enough that you should avoid them for anything you _need_ to look correct.
I've seen websites and apps where not only do the unicode symbols not display,
they get flat out replaced with different images, since some fonts organize
themselves differently. And if they don't display, Unicode doesn't gracefully
degrade, it just shows nothing.

It's always weirded me out and slightly annoyed me that emoji are associated
with Unicode at all, it's a terrible format for accessibility. The more
robust, markdown-ish way to do this would be to abandon attaching them to
Unicode characters entirely and wholesale switch to the Slack/Twitter
convention of spelling things out.

    
    
      :smile: :thumbsup: :cookie:
    

That way your unsupported emoji degrade perfectly, can be translated into
multiple languages or be given aliases, and are more future-proof/extensible.
If someone has a viewer that understands an emoji they can just swap out the
fallback text in-place. Emoji should be built like escalators, not elevators.

Plus, spelling them out allows you to use emoji like
:squirtle_squad_robbing_bank: or :children_standing_in_cornfield: even though
they haven't _technically_ made it into the standard yet. On an unrelated
note, for some reason the standards body has stopped responding to any of my
emails.

~~~
SahAssar
iconfonts and unicode icons are two different things. unicode icons are the
built in icons that renders correctly (but with slight variations) on any
modern device, iconfonts are basically your own icons set as a font, hopefully
using Private Use Areas for the codepoints.

~~~
danShumway
> on any modern device

This qualifier is why Unicode icons should be avoided where possible.

You're correct that Unicode icons are different from icon fonts in the sense
that they're standardized -- but the standard doesn't matter unless everyone
implements it; and as we can see on HN, plenty of platforms don't.

In practice, there are just too many platforms/devices that implement only
part of the Unicode standard, or that implement it incorrectly, or that extend
it with their own stuff.

~~~
SahAssar
HN just restricts the carachterset that you can use when commenting, just like
they don't support inline images or links with customized clickable text. By
that rationale we should stop using images on the web because "some platforms"
don't allow them in their comment fields.

In practice unicode icons are widely supported enough to use.

~~~
danShumway
I don't think this is a very good comparison -- the difference you're missing
is that if you embed inline images or custom links into a HN comment, they
degrade gracefully into URLs that anyone can use.

    
    
      [click me](https://google.com)
      <a href="https://google.com">click me</a>
      <img src="thiscatdoesnotexist.com" alt="this cat does not exist" />
    

In HTML, if a browser doesn't support images, they also degrade gracefully
into alt tags, which work with screen readers -- images can even be styled
with CSS to avoid document reflows. This is common practice on platforms like
email, where remote images will often be blocked.

I'm not saying avoid emoji, I'm saying avoid encoding them into a format that
literally stops rendering or turns into an undecipherable mess the moment it's
not fully supported -- especially since there are other encoding formats we
could use that would be just as good as Unicode and that wouldn't have any of
its downsides. In general, we should try to build escalators, not elevators.

~~~
SahAssar
> In general, we should try to build escalators, not elevators.

Agreed, but what is the better escalator in this case?

~~~
danShumway
IMO for most text-fields and markdown interfaces it's a shortcode.

    
    
      :smile: :calculator: :pikachu_brandishing_ketchup:
    

The only big downside to shortcodes are that they're more than one character
long, but there's no good way I can think of to have screenreader-accessible
emoji that doesn't contain a multiple-character description anyway.

Shortcodes will get passed properly through 99.9% of existing text processors
without any problems, so it's a really safe format to store things in.

I think the conversion to pictorial form should only happen at the display
layer. If you're writing HTML, I advocate for using an SVG with a title
attribute. Unicode emoji are already SVGs, so the only thing that changes is
you don't bundle your emoji into a font.

Even native applications understand how to automatically highlight things like
urls with the `[https://`](https://`) `[http://`](http://`) format, so my
personal vote is we just use shortcodes the same way we use URLs.

------
linayakunina
Thanks for sharing!

