search

jquery-archive / css-chassis

An attempt at creating an open standard for both CSS and JavaScript UI libraries.
https://css-chassis.com
Other
351 stars 67 forks source link

Determine which SVG icon set to use #1

Open scottgonzalez opened 9 years ago

scottgonzalez commented 9 years ago

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 commented 9 years ago

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

cbracco commented 9 years ago

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 commented 9 years ago

A few others i thought worth mentioning

cbracco commented 9 years ago

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 commented 9 years ago

I propose a different solution :

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 :

Screenshot Screenshot Screenshot Screenshot Screenshot

scottgonzalez commented 9 years ago

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 commented 9 years ago

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

jslegers commented 9 years ago

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 commented 9 years ago

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

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 commented 9 years ago

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 enter image description here 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 :

Icon fonts :

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 commented 9 years ago

@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 https://github.com/jquery/css-framework/issues/1#issuecomment-66277447.

When considering the other ways to use icon fonts that I mentioned in https://github.com/jquery/css-framework/issues/1#issuecomment-66277447, 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 https://github.com/jquery/css-framework/issues/1#issuecomment-66277447 :

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 commented 9 years ago

@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 commented 9 years ago

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 :

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 https://github.com/jquery/css-framework/issues/1#issuecomment-66277447 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 commented 9 years ago

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

jslegers commented 9 years ago

@sfrisk:

I'm currently predisposed.

How long will this meeting last? I should be able to join you guys as soon about half an hour to an hour

JoeBot0101 commented 9 years ago

@jslegers unfortunately the meeting has ended. Meeting time is Tuesdays, 1pm - 2pm EST

jslegers commented 9 years ago

@JoeBot0101 :

Meeting time is Tuesdays, 1pm - 2pm EST

That's equivalent to 7pm - 8pm CET, right? I'll try to be there on time next week.

Were you present? Can you give a heads-up on what was said about this particular issue?

scottgonzalez commented 9 years ago

http://irc.jquery.org/%23jquery-meeting/default_%23jquery-meeting_20141209.log.html#t10:04:30

sfrisk commented 9 years ago

@jslegers The decision was made that even though Unicode is interesting, moving forward SVG seems to be the better options when it comes to icons.

jslegers commented 9 years ago

@scottgonzalez & @sfrisk :

Thanks for the info.

http://irc.jquery.org/%23jquery-meeting/default_%23jquery-meeting_20141209.log.html#t10:04:30

I just tried to log in to http://webchat.freenode.net/?channels=#jquery-meeting but keep getting an error message stating Cannot send to channel: #jquery-meeting whenever I try to say something. Is this the expected behavior when logging in after the meeting is over? Or am I doing something wrong?

The decision was made that even though Unicode is interesting, moving forward SVG seems to be the better options when it comes to icons.

I see. I just read the logs @scottgonzalez linked to in his previous post.

It seems to me that most of the arguments I made in this issue in favor of icon fonts haven't been addressed, though.

Herebelow I'll add my remarks to the positions expressed during the meeting.

Some remarks :

beyond that there is if we care about the ability to use multiple colors gradients animations

If I look at the icons at http://livicons.com/, it seems to me that the Safari logo, the Chrome logo and the Reddit logo are the only icons that use more than one color.

Such multi-color icons can easily be implemented with icon fonts if you seperate the different components into different glyphs.

If you implement the Chrome logo using the :before hack, your HTML code could like this :

<div class="icon-chrome">
    <div class="icon-component-center"></div>
    <div class="icon-component-sw"></div>
    <div class="icon-component-se"></div>
    <div class="icon-component-n"></div>
</div>

If you implement the Chrome logo using PUA glyphs, your HTML code could like this :

<div class="icon-chrome">
    <div class="icon-component-center">&#58880;</div>
    <div class="icon-component-sw">&#58881;</div>
    <div class="icon-component-se">&#58882;</div>
    <div class="icon-component-n">&#58883;</div>
</div>

Sure, this is more complicated than implementing the ★ character to your HTML code, but it's still less complex than using inline SVG elements.

While using base64 encoded inline SVG backgrounds is as easy as defining a base64 string as the value of an HTML element's background image, it does make the tags within the SVG unreadable, which makes it impossible to modify the shapes within the image or determine which selectors to use when adding custom CSS to those shapes from looking at the image itself. That would not be the case with either inline SVG or HTML based icons (which you would modify or style the same way you'd modify or style any other part of the browser's DOM).

See also https://github.com/jquery/css-chassis/issues/1#issuecomment-66329378.

Our users will for sure not insert the characters themselves.

I'm not so sure about that. In fact, it's my impression that it's increasingly common for websites and applications to implement support for unicode based emoji by requiring users to copy-paste the characters into a text field. I expect this to only increase in popularity in the future.

Also, there's also the alternative of using HTML entities.

I know when I've done unicode stuff with font awesome, I use a cheat sheet

So do I.

You'd do exactly the same to get the proper UNICODE character or HTML entity to insert in your HTML code. So I don't really understand why anyone argue such an approach is more complex.

I also don't see how you could implement an SVG based icon set without using either a cheat sheet to get the proper classes (if you're using SVG backgrounds) or without copy-pasting the SVG code into your HTML from a cheat sheet (if you're using inline SVG).

As such, I would argue that each of these strategies has about the same complexity with respect to the steps that are required from a user to add an icon to their HTML page.

my argument against that - is if you're dealing with (for whatever reason) a non dev needs to be using the icons

As I said hereabove, using any of the icon font based strategies is as simple as copy-pasting a value from a cheat sheet.

also it would allow for custom icons

So does using UNICODE's PUA (private use area) for icons that aren't defined in the standard UNICODE planes, which is what most icon fonts do.

The problem with using UNICODE's PUA, however, is that there's no official standard. Already being a globally approved web standard is precisely what makes standard UNICODE planes a better choice than the PUA for any icons available in those planes.

As new symbols are added to future the unicode standard, this would provide further potential for standardizing any icons that currently are not included in standard UNICODE planes, allowing forward compatibility with other icon fonts and the development of multiple category based icon fonts that could be combined on the fly on a per project basis without having to edit the icon fonts.

Even customizing icon fonts has become child's play when using the Icomoon app. Not only that, but this app is already part of the standard toolkit of many graphic designers and web developers to create bloat-free cross-browser project specific icon fonts. My my employer's, is one of the many companies that uses the app for all web projects they create.

Customizing icon fonts wouldn't be necessary, however, as the use of category specific icon font sets instead of one big generic icon set containing all icons would already reduce the amount of bloat significantly.

Also, I would argue that the use of character or HTML entity based icons is pretty much native to HTML, especially for monochrome icons. The only thing missing to allow this to be implemented in a typical browser based environment, are fonts that support a wide range of useful characters. The reason I created the Emoji icon font, is to provide an idea of which icons are currently supported by standard UNICODE plains. This, in turn, could be used as a cheat sheet for creating any new icon fonts based on this same concept.

also our experience with support is that there are a lot of devices ( which we will support ) that have incomplete support

As explained in a previous post, that applies only to the :before hack. Any of the other methods described have far better browser support than either SVG backgrounds or inline SVG.

Any use of icon fonts that does not involve the :before hack has pretty much universal browser support, which includes even IE6-7 support.

Compare this with browser support for SVG. SVG support is lacking in IE<9, which means it's absent in IE8 (a browser for which -- according to the current specs -- should be included by CSS-chassis). If you want media queries inside your SVG elements, you'll need at least IE10.

IE is not the only browser that's behind on SVG support. It is also missing in the native Android browser up until 2.x. This browser even still doesn’t support media queries inside SVG images as of 4.1, making this thusfar unmentioned advantage of SVG images (which IMO would have otherwise been its greatest advantage) not usable in production environments.

Even in my current dev environment (OSX v10.x & Chrome v40.x), media queries seem to be pretty unstable :

screenshot source

Here's another SVG quirk that I just read about on Twitter : IE draws a Bézier curve even outside the SVG element it's in.

image source

Note that this is but the tip of the iceberg with respect to browser inconsistencies when using SVG. When experimenting with the potential of styling inline SVG for a D3.js mapping demo, I noticed multiple inconsistencies between how Firefox and Chrome rendered some pretty basic inline SVG. Unfortunately I did not care to document this behavior as there was no need for that at the time.

In contrast, the issue involving the :before isn't really that big an issue. it involves a webkit bug that got fixed on April 2012 and will become irrelevant in the near future if we consider that (1) people tend to replace their smartphones very fast and (2) the :before hack is so common future browser versions are unlikely to drop support for it in the foreseeable future.

so it sounds like people are generally favoring svg is that the case?

It does seem to be the case, but I would like to suggest that those favoring SVG icons first address the arguments raised in this issue before making this a final conclusion.

sfrisk commented 9 years ago

@jslegers The #jquery-meeting channel is only used for meetings, the rest of the time that channel is on mute. Since you tried to post in the meeting channel during a non meeting time, you were unable to post. As stated in the meeting thread, meetings only occur in #jquery-meeting. Development talk happens in a different channel, typically #jqueryui-dev, although a channel was just created for the project under #css-chassis to prevent cluttering up the UI channel with Chassis discussions.

jslegers commented 9 years ago

@sfrisk :

So there are two different channels for discussing matters in involving the css-chassis project, right? So there's the weekly meetings on #jquery-meeting and additional meetings in the #css-chassis channel, right? How exactly are the discussions in #css-chassis organised? Are they also periodical? Is there a schedule available? And are they invite only or are they open for any interested parties?

Also, will you consider not finalizing the decision to opt for SVG icons before the arguments I raised in previous posts of this issue are fully addressed? Judging by the log file provided by @scottgonzalez, I don't believe the many advantages of icon fonts and the various ways to use them have been properly assessed.

scottgonzalez commented 9 years ago

There are no meetings in #css-chassis, it's just an open channel for discussion.

cbracco commented 9 years ago

FWIW I like this comparison of both approaches: http://css-tricks.com/icon-fonts-vs-svg/

cbracco commented 9 years ago

The biggest advantage of icon fonts (as far as I can tell) is the IE6+ compatibility ... but with svg4everybody by @jonathantneal, you can get support back to IE6.

cbracco commented 9 years ago

I started out using icon fonts, and transitioned over to SVG (with the polyfill for projects that needed <IE9 compatibility) and I have had a more enjoyable experience with the SVGs. You have more control and more creative possibilities. The icon font always felt like a hack (I mean it is, right?). The polyfill is too, I suppose, but I guess my point is I usually spend less time building and styling SVGs than I do icon fonts.

jslegers commented 9 years ago

@cbracco :

I have had a more enjoyable experience with the SVGs. You have more control and more creative possibilities.

Could you please elaborate on why you believe the use of SVG is more flexible than the use of HTML elements in combination with icon fonts? Do you prefer inline SVGs embedded into your HTML, base64 encoded SVG backgrounds embedded into your CSS, SVG backgrounds loaded seperately by URL or SVG elements as an IMG elements?

Also, what about the inconsistent behavior of media queries inside SVG (relative to the image width except when inline) and the many other issues I mentioned at https://github.com/jquery/css-chassis/issues/1#issuecomment-66356978 and preceding comments?

The icon font always felt like a hack (I mean it is, right?).

The :before syntax that's used in popular icon fonts is a hack.

That doesn't make icon fonts a hack. In fact, icon fonts are about as native to HTML as it gets. All it requires to add support for icon fonts is a font that supports the required icons. I addressed this in detail in https://github.com/jquery/css-chassis/issues/1#issuecomment-66277447 and subsequent comments for this issue.

The main issue I have with icon fonts is that they're typically implemented using Unicode's Private Use Area, which is a range within UNICODE where anyone can freely add their own custom glyphs. The lack of any standards for the PUA makes icon fonts not really interchangeable or compatible with one another.

This can be alleviated, however, by using standard unicode planes for any icons supported by those planes. As this option thusfar seems to have been ignored by icon font developers, I created a proof-of-concept icon font to demonstrate how many of commonly used icons are already supported by the standard UNICODE planes and how a consistent look-and-feel for this diverse collection of icons can be actieved. Feel free to check it out at https://github.com/jslegers/emoji-icon-font and download or fork the project in case you'd like to experiment with it yourself.

With the increasing adoption of Emoji outside Japan, the number of standardized icons is likely to only increase as time progresses and may include the vast majority of common UI icons in the foreseeable future. I addressed this in https://github.com/jquery/css-chassis/issues/1#issuecomment-66277447

rxaviers commented 9 years ago

Maybe, it'd be good to start summarizing the decisions made here. The points everyone agree on, the open points, and so on. I personally do this in the description of the issue: an executive summary. It's just a suggestion... It avoids an endless forum.

jslegers commented 9 years ago

@rxaviers :

:+1:

@sfrisk

What are your thoughts on @rxaviers' proposal?

Maybe we could create a spreadsheet to offer an overview of the positions in favor or against the different ways to implement icons, so people don't need to go through every single comment? Do you -- being the project leader -- support this?

scottgonzalez commented 9 years ago

Maybe we could create a spreadsheet to offer an overview of the positions in favor or against the different ways to implement icons

@toddparker @scottjehl Don't you have one of these laying around somewhere? Perhaps a bit out of date, but certainly a much better starting point than nothing.

arschmitz commented 9 years ago

@scottgonzalez pretty sure I still have that somewhere also or at least access to it ill try to find it also.

cbracco commented 9 years ago

@jslegers this is the way I prefer using SVG for icons (with the polyfill for projects that need <IE9 support): http://css-tricks.com/svg-use-external-source/

jslegers commented 9 years ago

@cbracco :

@jslegers this is the way I prefer using SVG for icons (with the polyfill for projects that need <IE9 support): http://css-tricks.com/svg-use-external-source/

So you use a polyfill with Ajax based image retrieval and user agent sniffing for browser detection to support IE11 and below?

Why do you believe this kind approach is preferable to eg. inline SVG or base64-encoded SVGs embedded into the CSS? Sure, your approach involves the advantages of both inline SVG (you can style it along with other CSS + no additional HTTP requests) and embedded SVG (no duplication of your icons + no additional HTTP requests), but is that worth the lack of support from a browser as recent as IE11 for a CSS framework supposed to support IE8+ and supported to be promoted as a new standard for building new websites?

How well has this technique withstood real life use cases? How many people are actually using it in production code and are you (or anyone else) familiar with any browser comparisons for how different browsers behave when using this approach?

sfrisk commented 9 years ago

@jslegers As this is an ever evolving project, I think this decision will never be completely closed. However, in the interest of moving forward since one of the founding decisions of this project was to use svg, the decision today in meeting was unanimous, and I believe most of your concerns were already addressed earlier in this thread; I would like to continue under the assumption we'll be using SVG for the time being. Especially since the topic for this issue is the selection of the SVG icon set based upon our initial Skype call, not a discussion regarding if we should use SVG or UNICODE.

That being said, I'm happy to summarize the discussion in the issue if this will help make everything clearer.

Also, feel free to create a spreadsheet comparison of SVG vs Unicode, and we would be happy to discuss it any any time in #css-chassis channel. As @scottgonzalez stated, we treat that channel as being open for general discussion and the other Chassis members of the team and my I are there most of the day.

However, because our meetings have been running long already, I would prefer to not rehash this again in the next meeting (Tuesday, December 16, 2014 at 1:00 PM EST -- which you can add to your calendar here) unless after further conversations and comparisons in #css-chassis, others would like to reconsider the choice as well.

jslegers commented 9 years ago

@sfrisk :

Especially since the topic for this issue is the selection of the SVG icon set based upon our initial Skype call, not a discussion regarding if we should use SVG or UNICODE.

I do not see how the few arguments that were made during the Skype call were even remotely sufficient to already make that a permanent decision.

The additional research and experimentation that I've done since the initial Skype call suggests that the case for SVG isn't a clear cut case and that much of the case against icon fonts is specific to the most hacky way among several ways to use icon fonts. More specific, they do not address the universally supported approach of adding icons as Unicode characters or HTML entities in the HTML rather than using the infamous :before hack.

More in depth arguments for this position are provided in preceding comments.

I would like to continue under the assumption we'll be using SVG for the time being.

How does that make sense in light of the requirements for browser support that have been agreed upon and are mentioned at https://github.com/jquery/css-chassis/issues/3? IMO, the choice to use SVG explicitly contradicts the decision to provide support for iE8 and Android 2.3, which are both browsers that lack support for SVG altogether.

In contrast, icon fonts are universally supported and pretty much native to HTML when considering implementations alternative to the :before hack.

Also, the decision to go with SVG raises the following questions that are need to be agreed upon before any progress can be made :

dmethvin commented 9 years ago

Let's hear from some other voices. In particular I know Filament Group has looked at the options in depth so it would be great to know why they went with SVG.

toddparker commented 9 years ago

I'm not sure I have a spreadsheet handy, but I think Chris Coyier did a really good job comparing the two options here: http://css-tricks.com/icon-fonts-vs-svg/

I agree that SVGs are the better approach. Icon fonts are a transitional technique, like cufon or sIFR - sure, it worked at the time and it was better than making text as images but it was a pretty ugly hack. We now use the right tool, font-face for really embedding custom fonts and those other hacks are thankfully history.

Since font-face isn't supported everywhere and Unicode issue abound, you also need to approach web fonts with a fallback strategy in mind and it's sort of complex to get it all working. If a custom font used for content fails to load on a site, you get native fonts and everything is fine. However, if that happens with an icon-only button you get a cryptic character and unusable UI. Most devs think icons fonts are so easy because they simply don't plan for situations where they aren't supported. Info on how to use web fonts responsibly here: http://www.filamentgroup.com/lab/bulletproof_icon_fonts.html

SVG isn't supported everywhere either but there are a ton of options for automating fallback images. It's a lot more feasible to create fallbacks for SVG vs. Icon fonts. We at Filament Group made a grunt tool called grunticon for the task but pick the one that fits your workflow best.

Hope this is helpful. Happy to answer any follow-up questions.

arschmitz commented 9 years ago

@jslegers what we currently do in jQuery Mobile for svg support ( which does go back to ie8 ) is to use png fallbacks and we use a progressive enhancement approach based on filament groups grunticon which they made while they were working on the jQuery Mobile team.

Two differences i would suggest from what we do with jQuery Mobile is i would not use a :before pseudo element this has been troublesome. I would also suggest looking into using svg sprite sheets and png sprite sheets rather then the individual ones we use now.

https://github.com/filamentgroup/grunticon

The spreadsheet @scottgonzalez mentioned earlier can be found here https://docs.google.com/spreadsheet/ccc?key=0Ag5_yGvxpINRdHFYeUJPNnZMWUZKR2ItMEpRTXZPdUE#gid=0

and the test page used to create that can be found here http://www.filamentgroup.com/examples/grunticon-icon-test/

Also some initial research done by Filament group for jQuery mobile https://github.com/jquery/jquery-mobile/wiki/Fonts-for-icons---support-on-mobile-browsers

arschmitz commented 9 years ago

@toddparker Thats ok i found it :-) its actually still linked in the grunticon readme too :-p

toddparker commented 9 years ago

Thanks @arschmitz!

cvrebert commented 9 years ago

You poor folks have my sympathy for trying to support broken-ass Android 2.3, more than 3 years old w/ ~9.1% of Android's marketshare.

scottjehl commented 9 years ago

+1 to Todd’s assessment. SVG is designed for the job and brings some really interesting capabilities.

Chris Coyier’s coverage on CSS Tricks covers that in great depth.

On Dec 9, 2014, at 7:50 PM, Chris Rebert notifications@github.com wrote:

You poor folks have my sympathy for trying to support broken-ass Android 2.3, more than 3 years old w/ ~9.1% of Android's marketshare.

— Reply to this email directly or view it on GitHub.

jslegers commented 9 years ago

@toddparker, @arschmitz & @scottjehl :

Icon fonts are a transitional technique, like cufon or sIFR - sure, it worked at the time and it was better than making text as images but it was a pretty ugly hack.

Isn't that just a matter of a powerful technique being poorly implemented?

Isn't the use of the content rule in :before selector actually the worst of several ways to implement icons using unicode based fonts?

Would you still say icon fonts are a hack if you use them 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 the way icons are supposed to be presented in HTML and as close to a native implementation as it gets.

See also the Emoji icon font for a proof-of-concept icon font that illustrates the approach of using standardized UNICODE planes instead of the PUA for several hundreds of the many icons supported by those planes.

font-face isn't supported everywhere

What are you talking about? Font-face is one of the most universally implemented features.

While not perfect, it's far more universally supported than SVG.

image

Unicode issue abound

Which of these issues are still relevant when we ignore browsers that have been patched two years ago and the possibility to use standard unicode fonts for many of the icons?

Does the use of standardized planes, in fact, not actually favor the use of icon fonts?

Most devs think icons fonts are so easy because they simply don't plan for situations where they aren't supported.

I would agree that a reliable fallback option is important, but is a fallback option even needed when using unicode characters or HTML entities directly within the HTML?

Do you have any data on the percentage of browsers in use today that still has no support for @font-face? Caniuse mentions a coverage of 94.03%, which is likely to increase very fast when consider the rate at which people replace their smartphones.

scottjehl commented 9 years ago

I appreciate being tagging in on this thread, John. Not sure I have much more to add. I’d definitely recommend reading the posts on Chris C’s site and ours (bulletproof icon fonts especially, if you’re going that route). I believe those posts address each of your points below thoroughly, and also demonstrate some accessibility concerns with the particular patterns you’ve posted.

I offered my recommendation based on our experience working with both approaches and what we’ve found to be most flexible and reliable. Ultimately, it's up to you folks to decide what works best for you.

toddparker commented 9 years ago

Zach's presentation covers a lot of these issues and he can probably chime in when he's back from speaking at smashing conf next week on this very topic. He's knows a ton about the details of icon fonts, Unicode and the standards around each. The more you dig into this world, the murkier it gets. Despite the hype, there are serious compatibility and accessibility issues with icon fonts that are glossed over.

is a fallback option even needed when using unicode characters or HTML entities directly within the HTML?

It looks like you're suggesting using the "closest match" native Unicode characters directly in the html, then using a web font to make these look exactly as you want. If that's the case, we've found that will yield very unpredictable results across platforms. Some really good research here on what characters are safer than others but the truth is there are very few 'safe' native Unicode symbol characters. This site breaks it all down: http://unicode.johnholtripley.co.uk

In the example above, for example, I see a random square instead of an icon on my iOS device here:

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

There are also accessibility concerns with using characters like this. We did some testing on screen readers they read aloud stuff like "black filled star" for the star example or even more bizzare things that could be very confusing to screen readers. Other icon font techniques allow us to target descriptive text to assistive technologies in a more reliable way to communicate the meaning of the UI.

I actually tried to quantify the number of folks who are using browsers/devices that don't support web fonts. Rough numbers, but icon fonts aren't supported on ~370 million devices. That's double the number of iPads every sold. Info: docs.google.com/presentation/d…

Opera mini has huge numbers and Microsoft just announced that another 100 million devices will shift to this on new devices. This isn't just a legacy problem.

Lastly, I didn't say SVG didn't have drawbacks or greater compatibility. I just said that they are easier to provide fallbacks for and have quite a few advantages over icon fonts (multi-color, better positioning/antialiasing, etc.) that make them the best tool for the job ultimately.

If you want to use icon fonts, that's fine. I get why these are popular and switching to SVG may not work for everyone. That's why we spent so much time trying to think through how to use icon fonts responsibly. We created the only reliable feature test for font-face and a bunch of clear advice on fallback and usage in that article for devs that want to use this technique.

We just want to caution against simply tossing in icon font and not caring about where it fails. Every technique has places where it doesn't work, there is no silver bullet. We just want to make sure it's not a broken experience for those folks and we assess each option with solid data about pros/cons.

jonathantneal commented 9 years ago

Thanks for the ping, @cbracco. By now, we have at least a dozen amazing tools to resolve browser compatibility issues with SVGs, right? I imagine there are PNG, VML, and Flash fallbacks, at least. Cool, I won’t address this.

SVGs are a great tool for graphics. Fonts are a great tool for typography. Use them accordingly.

Some have mentioned accessibility issues with web fonts, so I’ll mention accessibility benefits with SVGs. Read Léonie Watson’s excellent article, Creating Accessible SVGs or look at some examples of accessible SVGs for JAWS, NVDA, and VoiceOver.

Oh, and don’t forget: SVGs are readable, editable, open sourcey things. They are built around a language that already structures the entire web as we know it. You don’t need a special IDE or compiler to create or edit them. They are what the www is all about.

jslegers commented 9 years ago

It looks like you're suggesting using the "closest match" native Unicode characters directly in the html, then using a web font to make these look exactly as you want.

It's a lot more elegant than that!

12 key principles :

  1. You use an _EXACT_ match native unicode character directly in the HTML. It is an exact match either with respect to the meaning of the icon, with respect to the look of the icon or both. There's a multitude of which I _selected 650 of the most interesting ones here_.
  2. If your editor can't display the character or you don't like using odd characters in your HTML, you can use an HTML entity instead. For example, you can use both &#9993; and &#x2709; to display an envelope.
  3. Styling icons requires minimal effort. The color, background and other styling of your icons will automaticly match that of the text next to it. Adding an icon to a multi-state add to favorites button can be as simple as changing <button>Add to favorites</button> to <button>&#9733; Add to favorites</button>.
  4. Like you would pick a regular font to match the look-and-feel of your site, you'd do the same with an icon font. Different icon fonts are interchangeable because the value of each icon is standardized and defined by UNICODE standards. You can also combine several minifonts or add all the icons you need to an existing regular font, eg. with the easy-to-use and already popular Icomoon app.
  5. 95% of all browsers support @font-face. They will produce a consistent look-and-feel for all of your icons. For that 5% that doesn't support @font-face, native UNICODE support can be used as a fallback for symbols that have nature support on these devices.
  6. the necessity to support languages like Hindi, Japanese and Mandarin makes support for UNICODE a requirement for every phone out there. The increasing popularity of Emoji in countries other than Japan is likely to result in the addition of even more icons with the arrival of UNICODE 8 and up, allowing icon sets to grow in a standardized fashion.
  7. Where an exact match native unicode character is not possible, you can use the private use area. This should, however, be standardized as much as possible to ensure future compatibility and icons should move to standard planes when support is added. If this approach were adopted by multiple popular icon fonts, this would also make it more likely for those icons to become part of a future Unicode standard, as happened with the addition of 250 Emoji in the UNICODE 7.0 release of June, 2014.
  8. All devices are already capable of displaying UNICODE if a font is present to show the characters. All desktop browsers (including IE6-IE8) already have full support for @font-face. Browsers not supporting @font-face are a small minority. That amounts to about 5% of the global market.
  9. The vast majority of that 5% that doesn't support @font-face involves cheap low-end phones for third world countries and other budget markets. They can be pretty much ignored if we consider the Western markt only, where anyone not using a somewhat advanced smartphone is considered a fossil by most.
  10. In the West, the remaining number of phones not supporting @font-face will continue to decrease very rapidly to even more insignificant numbers when considering the replacement rate of mobile phones.
  11. The memory restrictions of budget-aware low-end mobile phones are the only reason some more recent models still don't support @font-face. Not only is this totally irrelevant for the Western market, but it's just a matter of little time before memory capacity will have increased enough to provide @font-face support for even the most cheap-ass third world cell phones.
  12. When screen readers need to be prevented from accessing an icon, a combination of aria-hidden="true" and/or speak: none should do the trick if you add them to an HTML span element that wraps one or more icons you'd like to hide.

Also...

In the example above, for example, I see a random square instead of an icon on my iOS device here:

That's expected. However, if you use the same HTML code in combination with a the Emoji icon font you should get the expected result if you use an iPhone 4 or up. All that's required, really, is support for @font-face.

There are also accessibility concerns with using characters like this. We did some testing on screen readers they read aloud stuff like "black filled star" for the star example or even more bizzare things that could be very confusing to screen readers.

I know. I read your article. Wrapping any icon you want to hide in a span with the proper attributes should do the trick.

I actually tried to quantify the number of folks who are using browsers/devices that don't support web fonts. Rough numbers, but icon fonts aren't supported on ~370 million devices.

I would expect that number to be much smaller and drop to an insignificant number in the near future if you stick with the 12 principles I described in this comment because the requirements for the approach I described as much smaller than the more traditional "hacky" way to use icon fonts.

Also, I do think it's important to distinguish between the Asian market, the Third world market and the European market... as we did when discussing dropping IE6 support at a time when 1/4 of all Chinese were still using IE6. See below.

Opera mini has huge numbers and Microsoft just announced that another 100 million devices will shift to this on new devices. This isn't just a legacy problem.

We're talking about cheap low-end mobile phones here, which don't support @font-face due to the memory requirements of those devices. The vast majority of these devices end up on the Chinese market, the Indian market, the African market and other markets where price is a far more important issue than it is here in the West. Insisting on support of these phones is about as relevant to the Western market as support for IE6... if not less.

Consider that it's but a matter of little time before the Chinese market, the Indian market, the African market catch up with the rest of us. It's but a matter of time before they too can afford devices with browsers that support @font-face as pretty much every phone as well as every browser here in the West.

Also, consider that after the recent rapid decline of IE6 use in China, IE6 use in China is still about 5%. Yet, when >20% of the Chinese Internet users were still using that browsers most Western companies, frameworks and applications had already dropped support for IE6, even though supporting IE6 really isn't that hard. North-American and European developers decided they did not want to wait to move on to better technology because a market of 250,000,000 Chinese wouldn't or couldn't stop using IE6. So why not do these same when it involves @font-face support.

You really shouldn't care more about @font-face support any more than you should care about IE6. In fact, consider that even phones without @font-face would still show the correct symbols for characters that are natively supported by those devices. Consider where you'd be today if we had all decided to wait with dropping IE6 support until the Chinese market share was less than 5%.

IE6 usage on Feb 28, 2011 IE6 usage worldwide in February 2011, according to The Internet Explorer 6 Countdown

IE6 usage on Feb 28, 2011 IE6 usage worldwide in March 2014, according to The Internet Explorer 6 Countdown

IE6 use worldwide! IE6 use worldwide today, according to The Internet Explorer 6 Countdown

Lastly, I didn't say SVG didn't have drawbacks or greater compatibility. I just said that they are easier to provide fallbacks for and have quite a few advantages over icon fonts (multi-color, better positioning/antialiasing, etc.)

Several of the advantages that come with using SVG require SVG to be placed inline (especially the use of CSS for custom styling). If you use SVG images as backgrounds with PNG images as fallbacks, the downsides are far greater than the benefits and the benefits don't even come close the many advantages of using icon fonts.

Just consider how easy it is, using icon fonts, to add an icon to a button that has three states : normal, hover and active. You just need to make sure you have a font that supports that icon and add the icon to the button like this : <button>&#9733; Add to favorites</button>. Your icon will automatically adopt the text color and other CSS styles of your button in each of the three states. Change the look-and-feel of your website and the icons will adapt automatically. You get a lot of features with little to no effort.

Using the SVG background with PNG fallback approach requires two images for every color of your icon. In fact, you need to modify every SVG background to match the stylistic differences between the different states. Changing the look-and-feel of your website also requires that you manually change every single icon.

That makes the SVG + PNG fallback approach far less flexible. It requires more development time, more maintenance and provides less adaptability.

We created the only reliable feature test for font-face and a bunch of clear advice on fallback and usage in that article for devs that want to use this technique.

You guys were pioneers and well-respected for that. I really appreciate the work you guys did and do believe your results were very reliable with respect to the technology available at that time.

I also believe, however, that it is time to re-evaluate your conclusions about two years after the initial release of Grunticon. The mobile market changes far more rapidly than the desktop market and different approaches to icon fonts can reduce many of the issues you guys experienced.

Every technique has places where it doesn't work, there is no silver bullet. We just want to make sure it's not a broken experience for those folks and we assess each option with solid data about pros/cons.

While @zachleat's 01/13/2014 article does raise some valid issues about using icon fonts today, it doesn't take into account the different approach I'm taking with using unicode characters directly inside the HTML or as HTML entities. It doesn't take into account the use of standard unicode characters in combination with a webfont to ensure support for otherwise unsupported characters, the lack of mobile support for @font-face being largely region-specific and many other issues raised throughout this issue. If he has some time to join this discussion, I would really love to get his feedback, though.

The following icons can all are but some of the many icons that can all be implemented as _EXACT_ matches with standard UNICODE characters and are a subset of the Emoji icon font :

Screenshot Screenshot Screenshot

scottgonzalez commented 9 years ago

I apologize for chiming in without actually paying much attention to this issue, but I feel the need to reiterate what I said in IRC, regarding the following:

If your editor can't display the character or you don't like using odd characters in your HTML, you can use an HTML entity instead. For example, you can use both ✉ and ✉ to display an envelope.

If we require our users to include the actual character, whether encoded or not, we're going to lose out on a ton of potential users. Developers and designers don't want to be constantly referencing icon lists and copy pasting the icons.

jslegers commented 9 years ago

@scottgonzalez:

Developers and designers don't want to be constantly referencing icon lists and copy pasting the icons.

Copy-pasting a character or HTML entity is no more or less complicated than copy-pasting a CSS class like .icon-search or .icon-print from a cheat sheet.

The latter may be easier to memorize, but who really does that? @sfrisk stated at the meeting last Tuesday :

I know when I've done unicode stuff with font awesome, I use a cheat sheet

I've been using Font Awesome v3.2.1 in Cascade Framework 1.x myself, which uses a syntax that IMO is much easier to remember than the one the currently use. Even when sticking to this same icon set, I keep going back to the docs whenever I need an icon, because I just can't remember eg. whether the icon class to use for a search field icon-search or icon-find and whether the icon class for a print button is .icon-print or .icon-printer. i can't remember because I don't need to and we all tend to be lazy whenever there's no punishment for it.

It would be an illusion to think that most users would be able to use icons without having to look up either the corresponding CSS class, the HTML entity value or the UNICODE character itself. Whatever implementation you use, people just won't memorize your icons and cheat sheets will remain important.

scottgonzalez commented 9 years ago

I'd just like to point out that what others do regarding browser support isn't too relevant. Look at how long jQuery and jQuery UI supported IE6. Also, concentrating on the Western market isn't a goal for us.