Determine which SVG icon set to use

[scottgonzalez]

Rather than create our own icons, we should pick an existing icon set. In the planning meeting, everyone agreed to use SVG icons and Google's Material Design icons were suggested. We should review a few icon sets and make a decision.

We should also document the process for using custom icons.

[sfrisk]

Does anyone have a preference on icon sets? If not, I can come up with a list of different icon sets for review.

[cbracco]

At a glance, the Material Design icons look nice. Typicons and Entypo seem like solid options as well. I was never particularly fond of the de-facto Font Awesome (and its awkward 14px grid size), but that might just be personal taste.

[arschmitz]

A few others i thought worth mentioning

• Iconic - Open source, svg and font-icon, 233 icons, supports both bootstrap and foundation https://useiconic.com/open/
• Flat Icon - huge variety ( 544 icon packs ) svg, png, font icon, psd, png http://www.flaticon.com/packs/
• ion icons - font-icon, png open, source http://ionicons.com/
• The noun Project growing library contributed by various artists http://thenounproject.com/term/open-source/8233/

[cbracco]

Totally forgot about Iconic! That is a solid choice too.

Found the Material Design icons on that flaticon.com website, easier to preview them here: http://www.flaticon.com/packs/material-design

[jslegers]

I propose a different solution :

• Focus on icons that are already supported by standardized UNICODE planes (❤, ☃,❄,★,☂,☭,⎗, ⎘,...)
• Combine icons from various icon sets to be as feature complete as possible, without losing much visual consistency
• Use the Icomoon app to build the icon set

Using as much of the standardized UNICODE planes provides future compatibility with other icon fonts that do the same, as well as Emojis (which are becoming increasingly popular). The latter is the reason I called this experimental font the "Emoji icon font".

A proof of concept with _650 glyphs_ can be found here.

Note :

For sake of performance and flexibility, such a font could be split up into several sub-fonts based on content (eg. 'food icons', 'holiday icons', 'arrows', 'chess icons', ...). They could then be merged or used as individual fonts on a per project basis. As they use standard UNICODE values, there would not be any compatibility issue when combining several of these fonts individually, nor with combining these fonts with regular fonts.

That means you could do something like this :

body {
    font-family: opensans, sans-serif;
}

.rate, .chat {
    font-family: icons-web, opensans, sans-serif;
}

.icon {
    font-family: icons-web, icons-arrows, icons-social,
                 icons-holiday, opensans, sans-serif;
}

<div class='rate'>
    I rate this movie ★★★★☆
</div>

<p>
    You'll need to press the <span class="icon">⎗</span>
    button to go to the previous page.
<p>

<div class="chat">
   <p class="person1">I ❤ you!!<p>
   <p class="person2">I ❤ you too!!<p>
   <p class="person1">☺☺☺☺☺<p>
   <p class="person2">LOLZ<p>
</div>

IMO, this is a much cleaner, much more flexible and much more futureproof way to use icons in HTML/CSS than any other technique I've seen so far.

Of course, you will need UTF-8 support to make optimal use of this technique, but UTF-8 is already more or less the standard globally.

Note :

You could still use the oldschool .icon-print:before syntax if you don't want to use a cheat sheet for copy-pasting unicode values or the actual glyphs. This, however, should not be the recommended way if you're using standardized UNICODE planes for your icon fonts.

As mentioned in the first conf call, the .icon-print:before is indeed a hack that shouldn't be encouraged in the future. That doesn't mean, however, that there's anything wrong with icon fonts per se. In fact, building the Emoji icon font only made me more convinced that icon fonts do that their value in the long run and are thé way to go if we consider some the alternative syntaxes I proposed.

Some icons from the Emoji icon font :

[scottgonzalez]

Basing the icons on Unicode is an interesting idea. Seems like a good thing to explore, thanks for digging in and building the proof of concept.

I also just came across this set of icon packs: https://www.pixelapse.com/showcases/icons

[cvrebert]

Beware non-BMP CSS content on old Android/WebKit versions: http://stackoverflow.com/questions/9241519/webkit-css-content-unicode-bug , twbs/bootstrap#10106

[jslegers]

Basing the icons on Unicode is an interesting idea. Seems like a good thing to explore, thanks for digging in and building the proof of concept.

You're welcome. I'm very glad to see you agree with the potential of putting as many icons as possible in the standardized UNICODE planes rather than the non-standardized Private Use Area (which is where icon fonts typically store their glyphs).

Please do not hesitate to provide any questions, remarks or suggestions with regards to the proof of concept you or other members of the team may have.

Beware non-BMP CSS content on old Android/WebKit versions

The strategy I described would allow us to use each of the following methods to add filled and non-filled starts to an HTML page (which is commonly used for ratings).

<!-- Method 1 -->
<!--- * * * * * * * * * * * * -->
<!-- Set a font-family for an entire HTML element -->
<!-- Define your icon fonts in your CSS font-family after your regular fonts  -->
<!-- This means that regular characters are default. Icons are a fallback  -->
<!-- Use UTF-8 characters directly in your HTML for improved human readability -->
<div class="rate"><p>I rate this movie ★★★★☆!!</p></div>

<!-- Method 2 -->
<!--- * * * * * * * * * * * * -->
<!-- Set a font-family for an entire HTML element -->
<!-- Define your icon fonts in your CSS font-family after your regular fonts  -->
<!-- This means that regular characters are default. Icons are a fallback  -->
<!-- Use entity codes in your HTML when UTF-8 support is uncertain -->
<div class="rate"><p>I rate this movie &#9733;&#9733;&#9733;&#9733;&#9734;!!</p></div>

<!-- Method 3 -->
<!--- * * * * * * * * * * * * -->
<!-- Set a font-family only for the icons but not the HTML elements that include them -->
<!-- Define your icon fonts in your CSS font-family before your regular fonts  -->
<!-- This means that icons are default. Regular characters are a fallback  -->
<!-- Use UTF-8 characters directly in your HTML for improved human readability -->
<p>I rate this movie <span class="icon">★★★★☆</span>!!</p>

<!-- Method 4 -->
<!--- * * * * * * * * * * * * -->
<!-- Set a font-family only for the icons but not the HTML elements that include them -->
<!-- Define your icon fonts in your CSS font-family before your regular fonts  -->
<!-- This means that icons are default. Regular characters are a fallback  -->
<!-- Use entity codes in your HTML when UTF-8 support is uncertain -->
<p>I rate this movie <span class="icon">&#9733;&#9733;&#9733;&#9733;&#9734;</span>!!</p>

<!-- Method 5 -->
<!--- * * * * * * * * * * * * -->
<!-- Set a font-family only for the icons and use a separate HTML tag for each icon -->
<!-- Define your icon fonts in your CSS font-family before your regular fonts  -->
<!-- This means that icons are default. Regular characters are a fallback  -->
<!-- Use UTF-8 characters directly in your HTML for improved human readability -->
<p>I rate this movie
    <span class="icon">★</span>
    <span class="icon">★</span>
    <span class="icon">★</span>
    <span class="icon">★</span>
    <span class="icon">☆</span>
    !!
</p>

<!-- Method 6 -->
<!--- * * * * * * * * * * * * -->
<!-- Set a font-family only for the icons and use a separate HTML tag for each icon -->
<!-- Define your icon fonts in your CSS font-family before your regular fonts  -->
<!-- This means that icons are default. Regular characters are a fallback  -->
<!-- Use entity codes in your HTML when UTF-8 support is uncertain -->
<p>I rate this movie
    <span class="icon">&#9733;</span>
    <span class="icon">&#9733;</span>
    <span class="icon">&#9733;</span>
    <span class="icon">&#9733;</span>
    <span class="icon">&#9734;</span>
    !!
</p>

<!-- Method 7-->
<!--- * * * * * * * * * * * * -->
<!-- Set a font-family only for the icons and use a separate HTML tag for each icon -->
<!-- Define your icon fonts in your CSS font-family before your regular fonts  -->
<!-- This means that icons are default. Regular characters are a fallback  -->
<!-- Use the 'content' style rule with a ':before selector' in your CSS -->
<p>I rate this movie
    <span class="icon icon-star"></span>
    <span class="icon icon-star"></span>
    <span class="icon icon-star"></span>
    <span class="icon icon-star"></span>
    <span class="icon icon-star-unfilled"></span>
    !!
</p>

The issue with old Android/WebKit versions _only_ involves method 7, where you need the content style rule with an escape sequence to set the value of the icon.

Method 1 to 6 does not require the content style rule nor any other style rule with an escape sequence. All that's required to get those methods to work, is a browser that (1) supports @font-face and (2) is capable of displaying unicode glyphs. AFAIK this is universally supported. Even IE6-IE7 offer support for @font-face and displaying unicode glyphs.

[arschmitz]

@jslegers I really like the idea of unicode font glyphs in theory but i have a few concerns.

1.) In the original call about this framework we decided to go with svg icons rather than an icon font for a few reasons which are still valid.

• Fallback In previous testing for jQuery Mobile and Filament Groups Grunticon we found that there was not a robust enough support test for icon fonts and there were false positives where it was technically supported they did not render in a usable way
• Multi color support - with font icons you are limited to a single color
• Animation - its possible to animate svg icons it is not possible to do this with font icons

2.) Accessibility - Any of the methods above that place the unicode char directly into the the markup will result in this character being announced by the screen reader which can lead to very awkward and or double announcements

3.) Any of the methods which do not use a separate element for each icon are very very hard to deal with when it comes to javascript widgets. :pseudo elements cant be selected directly in js and by just placing it in the text node it becomes even worse. So any widget which attempts to manage the icon becomes very complicated.

4.) Forcing the unicode to be used directly seems really awkward for developers using the framework. We want this to be usable by people who have no coding ability or knowledge at all and i think unicode may be a little intimidating. but using the content rule has its own problems mentioned by @cvrebert

So while i like the idea behind this im not sure if it benefits out weigh the potential issues

[jslegers]

With regards to my preference for icon fonts vs background-images, consider the following.

Background images vs icon fonts

For optimal performance, it's best to embed an image in your CSS file by base-encoding it. The following code is the base64 for and SVG version of the icon :

/* size: 0.9kb */
url(data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48IURPQ1RZUEUgc3ZnIFBVQkxJQyAiLS8vVzNDLy9EVEQgU1ZHIDEuMS8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9HcmFwaGljcy9TVkcvMS4xL0RURC9zdmcxMS5kdGQiPjxzdmcgdmVyc2lvbj0iMS4xIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB3aWR0aD0iMTYiIGhlaWdodD0iMjgiIHZpZXdCb3g9IjAgMCAxNiAyOCI+PGcgaWQ9Imljb21vb24taWdub3JlIj48L2c+PHBhdGggZD0iTTE2IDE3cTAgMC40MDYtMC4yOTcgMC43MDNsLTcgN3EtMC4yOTcgMC4yOTctMC43MDMgMC4yOTd0LTAuNzAzLTAuMjk3bC03LTdxLTAuMjk3LTAuMjk3LTAuMjk3LTAuNzAzdDAuMjk3LTAuNzAzIDAuNzAzLTAuMjk3aDE0cTAuNDA2IDAgMC43MDMgMC4yOTd0MC4yOTcgMC43MDN6TTE2IDExcTAgMC40MDYtMC4yOTcgMC43MDN0LTAuNzAzIDAuMjk3aC0xNHEtMC40MDYgMC0wLjcwMy0wLjI5N3QtMC4yOTctMC43MDMgMC4yOTctMC43MDNsNy03cTAuMjk3LTAuMjk3IDAuNzAzLTAuMjk3dDAuNzAzIDAuMjk3bDcgN3EwLjI5NyAwLjI5NyAwLjI5NyAwLjcwM3oiIGZpbGw9IiMwMDAwMDAiPjwvcGF0aD48L3N2Zz4=

When to use background-images or fonts

For many use cases, SVG-based background images and icon fonts are largely equivalent with regards to performance and flexibility. To decide which to pick, consider the following differences:

SVG images :

• They can have multiple colors
• They can embed their own CSS and/or be styled by the HTML document
• They can be loaded as a seperate file, embedded in CSS AND embedded in HTML
• Each symbol is represented by XML code or base64 code. You cannot use the character directly within your code editor or use an HTML entity
• Multiple uses of the same symbol implies duplication of the symbol when XML code is embedded in the HTML. Duplication is not required when embedding the file in the CSS or loading it as a seperate file
• You can not use color, font-size, line-height, background-color or other font related styling rules to change the display of your icon, but you can reference different components of the icon as shapes individually.
• You need some knowledge of SVG and/or base64 encoding
• Limited or no support in old versions of IE

Icon fonts :

• An icon can have but one fill color, one background color, etc.
• An icon can be embedded in CSS or HTML. In HTML, you can use the character directly or use an HTML entity to represent it.
• Some symbols can be displayed without the use of a webfont. Most symbols cannot.
• Multiple uses of the same symbol implies duplication of the symbol when your character embedded in the HTML. Duplication is not required when embedding the file in the CSS.
• You can use color, font-size, line-height, background-color or other font related styling rules to change the display of your icon
• You need no special technical knowledge
• Support in all major browsers, including old versions of IE

Personally, I would recommend the use of background-images only when you need multiple colors and those color can't be achieved by means of color, background-color and other color-related CSS rules for fonts.

The main benefit of using SVG images is that you can give different components of a symbol their own styling. If you embed your SVG XML code in the HTML document, this is very similar to styling the HTML. This would, however, result in a web page that uses both HTML tags and SVG tags, which could significantly reduce the readability of a webpage. It also adds extra bloat if the symbol is repeated across multiple pages and you need to consider that old versions of IE have no or limited support for SVG.

[jslegers]

@arschmitz :

1.) In the original call about this framework we decided to go with svg icons rather than an icon font for a few reasons which are still valid.

At that point, I was totally unfamiliar with any arguments against icon fonts. As I seemed to be the only one not familiar with those arguments, I decided not to accept the decision in favor of SVG background images until I had done sufficient research into the arguments favoring SVG instead of icon fonts.

After concluding my research, I have come to the conclusion that most of the arguments against icon fonts are valid only for the traditional :before hack -- see method 7 at #1 (comment).

When considering the other ways to use icon fonts that I mentioned in #1 (comment), I believe icon fonts are a far superior solution for most use cases.

that there was not a robust enough support test for icon fonts and there were false positives where it was technically supported they did not render in a usable way

The rendering issues you're refering to typically refer to method 7 only.

There are but two requirements for any of the first 6 methods mentioned in #1 (comment) :

• Support for webfonts, by means of @font-face
• The capacity to display any character or any webfont that's loaded by means of @font-face

These requirements are so common even IE6-IE7 support this!

Multi color support - with font icons you are limited to a single color

Many( if not most) uses cases do not require anything that can't be achieved by setting the color, background or text-shadow and other CSS rules of a single glyph.

While there are obviously use cases that do, I don't believe those use cases are sufficiently common to dismiss icon fonts and opt for SVG icons instead. This doesn't counter the many benefits icon fonts have over SVG background images.

Animation - its possible to animate svg icons it is not possible to do this with font icons

It you just want to alter the position, size, rotation angle, opacity and/or other features of the entire icon, it is actually easier to animate icon font based icons than it is to animate SVG based icons. In fact, it would be exactly like animating any other part of your HTML dom, using CSS3 rules like transition , translation and/or @keyframes.

Sure, its true can't animate components of an icon font base icon. However, such use cases are far less common, usually a lot more complicated and are typically implemented by using a library like D3.js or Vivus to take care of the heavy lifting.

So you argue the project should also include D3.js or Vivus? Should it have its own JS library, perhaps, to take care of complex animations?

Maybe I'm missing something here, but it seems to me that the number of use cases that (1) require different components of an icon to have their own animations and (2) can easily be implemented without additional technical knowledge or a JS library is so small we can pretty much ignore it.

2.) Accessibility - Any of the methods above that place the unicode char directly into the the markup will result in this character being announced by the screen reader which can lead to very awkward and or double announcements

First of all, these symbols have a rather fixed meaning or depiction. I'm no expert on accessibility, but I'd be very surprised if screen readers are incapable of reading symbols like ❤ or ★

When screen readers do need to be prevented from accessing an icon, aria-hidden="true" and/or speak: none should do the trick.

3.) Any of the methods which do not use a separate element for each icon are very very hard to deal with when it comes to javascript widgets.

If you use a separate element for your icon, it replacing values would be dead simple. Then, you'd just need to do something like myIcon.innerHTML = "\2606" to replace ★ with ☆.

Replacing ★ with ☆(or vice versa) within a longer string would be no different from replacing 'open' with 'close' within a longer string. It would be something like str.replace(/\2605/g,"\2606");, with the innerHTML of your element being the value of str.

If you're arguing that's not simple enough for the most entry level frontend developers, a jQuery plugin could be provided with a method defined with the interface function replaceText(search, replace) { ... }. This method would abstract away the entire process and allow users to just use $('.rate-me').replaceText("\2605", "\2606") to replace any substring of the innerHTML of elements that have the .rate-me class. I don't think such a simplification would be necessary, however, as the replacement of a substring of a string is already about a simple as it gets.

Or am I missing something here?!

4.) Forcing the unicode to be used directly seems really awkward for developers using the framework. We want this to be usable by people who have no coding ability or knowledge at all and i think unicode may be a little intimidating.

Embedding an SVG in a CSS file or or HTML file and adding CSS styling for that SVG requires technical knowledge most entry level HTML/CSS codes do not have.

Adding a webfont to a CSS file and using a unicode character of HTML entity in your HTML code is not only less complex, but it's also a skill many entry level HTML/CSS coders already have.

[arschmitz]

@jslegers Sorry about the double post not sure what happened there i had not intended to double post i actually had not even seen your post yet ( timing ).

As far as multi color and animation support i only meant that but us using an svg icon set it makes it possible for people who do need these things to implement them more seamlessly. Another advantage of svg's is if you as a developer want to be able to edit the icons for any reason its much easier to open up an svg in something like illustrator and edit it then it is to edit a font file.

Embedding an SVG in a CSS file or or HTML file and adding CSS styling for that SVG requires technical knowledge most entry level HTML/CSS codes do not have.

The developers would never be adding or embedding the svgs themselves. This would all be handled as part of creating the distribution files so this is a non issue unless people wanted to add their own icons in which case they would likely just download another icon pack and include it separately or as part of their own build process.

If you use a separate element for your icon, it replacing values would be dead simple. Then, you'd just need to do something like myIcon.innerHTML = "\2606" to replace ★ with ☆.

As i said any method that "Any of the methods which do not use a separate element for each icon"

Replacing ★ with ☆(or vice versa) within a longer string would be no different from replacing 'open' with 'close' within a longer string. It would be something like str.replace(/\2605/g,"\2606");, with the innerHTML of your element being the value of str.

What about when you have a widget with a boolean icon option and you need to remove all icons regardless of what icon they are using individual elements you can do something like $( ".ui-icon" ) to select all icons now you would have to know every potential icon string and parse the text to look for and remove them. You also cant track icons within js easily because you can just add each icon to a collection of elements. You will need to track the parent element as well as the exact icon being used on it to later be able to do a search and replace. Also how do you deal with widget where you allow the icon to be added by the developer in their markup but need to be able to later dynamically change the icon. How do you do this unless you force the developer to pass the string for the original icon they used as an option, which I think is pretty ugly.

First of all, these symbols have a rather fixed meaning or depiction. I'm no expert on accessibility, but I'd be very surprised if screen readers are incapable of reading symbols like ❤ or ★

Screen readers do generally announce them properly but this is not always desirable. You may be using an icon for something other then the direct meaning of its name. For example just because you use an airplane icon does not mean you want it to say airplane when being read. Even when it is correct in its meaning double announcements can be really annoying which would often be the case. Icons are generally just decoration also. This is why icons are generally placed in such a way that they are not announced at all.

When screen readers do need to be prevented from accessing an icon, aria-hidden="true" and/or speak: none should do the trick.

If you don't put each icon in its own element you cant apply things like aria or other attributes with out applying them to the whole text of the element which is obviously not acceptable.

I agree none of these things alone are a deal breaker however it seems like the solutions to them can be contradictory to each other. I like the idea in theory but i have technical concerns

[jslegers]

As far as multi color and animation support i only meant that but us using an svg icon set it makes it possible for people who do need these things to implement them more seamlessly.

Even when you need multi-color support, there are other alternatives.

Consider the following way to create a Filezilla logo :

<div class="icon-filezilla">
    <div class="icon-component-background"></div>
    <div class="icon-component-text"></div>
</div>

You could then use .icon-component-background to define the red background and `icon-component-text. to define the text. For both components, you'd have the choice to :

1. use a base64-encoded image embedded in the CSS
2. use an image that's part of a sprite
3. use a standalone image
4. use glyph defined in an icon font

My proposal is to provide an icon font with common symbols to provide an easy way to go work with choice 4. Nevertheless, this can perfectly be combined with any of the other three options, which I don't think should be included in a CSS framework.

Another advantage of svg's is if you as a developer want to be able to edit the icons for any reason its much easier to open up an svg in something like illustrator and edit it then it is to edit a font file.

IMO, using the Icomoon app to create and/or modify font files is a lot easier than using illustrator.

The developers would never be adding or embedding the svgs themselves.

That seems like a very bad idea to me. I don't see how to avoid ending up with either a very rigid (and thus mostly useless) boilerplate or a poorly scalable maintenance nightmare.

As i said any method that "Any of the methods which do not use a separate element for each icon"

AFAIK, that's still no more complicated than using str.replace, as I explained in my previous post.

What about when you have a widget with a boolean icon option and you need to remove all icons regardless of what icon they are

You have two options :

• Use <span class='icon'></span> as a wrapper around every relevant icon or set of icons. Then, you just need to replace the innerHTML of those elements with an empty string.
• Define an array that contains the ranges of unicode values that need to be replaced by an empty string and another array with the selectors that need to be processed. Then, you just need to use a single str.replace with a Regex containing all the relevant ranges and replace the characters matching the ranges with an empty string for the innerHTML of all the elements that match the selectors.

Option two is only slightly more complicated than option one.

How do you do this unless you force the developer to pass the string for the original icon they used as an option, which I think is pretty ugly.

Something like this, you mean?!?

<button data-state='open' data-icon-open='open' data-icon-close='close'>open</button>

I don't see what's wrong with that, although it isn't the implementation I would prefer.

You may be using an icon for something other then the direct meaning of its name. [...] This is why icons are generally placed in such a way that they are not announced at all.

Again, aria-hidden="true" and/or speak: none should take care of those cases.

If you don't put each icon in its own element you cant apply things like aria or other attributes with out applying them to the whole text of the element which is obviously not acceptable.

I guess each of the 7 methods I mentioned at #1 (comment) have their own positives and negatives. Yet, that's precisely the beauty of it. You have the _choice_ to pick the best method for your use case, rather than being forced to use a method that's optimized for one range of used cases but works suboptimal for all other use cases.

I believe the greatest power of a CSS framework is not the procedures it requires you to use, but rather its capacity for getting out of the way. This, I believe, applies not just to the general architecture of UI components but also its approach to icons, transparence, gradients, etc.

[sfrisk]

@jslegers We're discussing this in the weekly meeting right now, if you would like to join us.