33 Beautiful Open-Source Icon Sets | Hacker News Reader

33 Beautiful Open-Source Icon Sets

blog.usepastel.com

118 pointsalokepillai15 comments

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/. 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.

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

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/GNOME_Desktop_icons

Breeze is a bit more 'modern' and would also work well on HiDPI: 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

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.

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

> 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.

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.

> 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.

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.

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.

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

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

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://` `http://` format, so my personal vote is we just use shortcodes the same way we use URLs.

the problem above is purely how HN have done the site, I'm guessing they don't save unicode text ( possibly ascii ) as when you load up the text again all the unicode is stripped from the message

You're right, but that's also kind of the point I'm making -- that your emoji can get stripped or broken purely because a random site or step in your display process decides not to handle the full Unicode.

Unicode emoji relies on sites/platforms:

A) choosing to support the full Unicode set

B) Being up-to-date on the current spec and having glyphs to display for the entire set

Regardless of whether or not it's easy to support -- many, many sites and platforms in the real world don't. When they don't support the full spec, you get invisible characters that can't degrade gracefully, can't be read by screen readers, and that break copy-paste.

I still run into garbled text online that's the result of people copying and pasting smart quotes between platforms that won't render them. Platforms are never gonna catch up to a living spec that is regularly extended, so it's preferable to avoid "novel" Unicode characters and use something that degrades gracefully instead.

Thanks for sharing!

Reply on news.ycombinator.com