CSS font-family fallback for icon font?

Question

My IDE inspects my CSS files, and complains if I put a font-family rule which does not have a generic fallback. In general, I have to agree with my IDE, and I will happily add the font callback.

Example:

.selector {
  font-family: Arial;  /* IDE complains. */
  font-family: Arial, sans-serif;  /* IDE is happy. */
}

However, sometime the font-family is an icon font (I think fontawesome is one of those), and a fallback does not really make sense. Or does it?

.my-icon {
  font-family: 'my-icon-font';  /* IDE complains. */
  font-family: 'my-icon-font', serif;  /* IDE is happy, but it does not make sense. */
}

Question

Could there be any sensible fallback that would make sense to append to a font-family rule with an icon font?

Additional motivation

In my case, it is mainly my IDE that is nudging me to add a generic font callback. As a last resort I could disable, suppress or ignore this inspection.

However, in other teams there might be strict rules about code conventions, perhaps even a mechanism that blocks commits if they do not comply.

Or what if I am the author of a code inspection tool, or in the process of defining the coding conventions to be used in a project? Then I definitely want to know what would be the "correct" or smartest way to do this :)

Equiangular

Check the W3C specs on font-family fallbacks. It looks to me that you encountered an IDE developers logic error. Have you tried adding the same font-name twice? Not trying to be smart, but who rules, You or the IDE? – Berke

To be fair to the IDE developer: For regular fonts, it is a good practice to put the font fallback. How would an IDE distinguish icon fonts from regular fonts? And of course the inspection is optional, it can be globally disabled or it can be suppressed for a single instance with an IDE-specific comment (which does look out of place in public code). – Equiangular

As for "who rules, You or the IDE?", of course it should be me. But having an inspection warning count of zero is valuable, because it makes it easier to spot new problems. – Equiangular

Search W3 CSS Fonts Module Level 3 for 'fallback' and you will find the answer to your question. That is to say, the text says nothing about a fallback being [MANDATORY]. As I said before, it is an IDE glitch, developer typo, company rule or what ever, but not a W3C CSS3 rule. Ignore, disable or get another IDE. You are right about trying be 'warning' free, same sentiment here, but that itself should not become a rule, just a goal. – Berke

Simpler logic: if you have no 'fallback' to give, then there's no 'fallback' to add. Missing icon: browsers show a tiny square with the hex-code of the missing character. This behaviour has been implemented for ages already, since, I dunno, 1653 A.D.... – Berke

IDE inspection is not always about what is technically mandatory, but what is recommended. My IDE (PhpStorm) has "Missing generic font name" under "Probably bugs", which indicates "might be wrong" but not "definitely wrong". My conclusion from this exchange is that an icon font is indeed a case where a font fallback is not necessary or useful, so I should either ignore the IDE warning or disable the inspection altogether. – Equiangular

@RenevanderLende sorry but now sonar cube also flags this as css critical error – Lobule

To OP and @MiKr13, an IDE should simply not flag a missing [OPTIONAL] value as a critical error. A warning at most, or maybe an informational message. To me W3C (with all its flaws and/or inconsistencies) has the final word. In general, an IDE should check against the prevailing rules/syntax, not make its own. Special IDE's should check against the rules too, but give advice on special rules (e.g. advice/rules on colors for 'colorblindness') and leave it up to you to consider it as an error or not. – Berke

Perhaps a good solution would be a font that shows "fallback icons", e.g. a graphical question mark. I don't think such a font exists or is available on any system by default, but if it did, that would be the correct answer. – Equiangular

Working under the assumption that W3C has 'the final word' is not a wise thing to do for web devs imho. It should be 'the customer has final word', or 'the user has final word' or 'common sense has final word', but definitely NOT w3c. If you have taken the w3c as gospel the last years, you will have spent valuable time on XHTML, XSLT, deprecating <b> and <i> and a whole bunch of other things that the w3c recommended or removed from the standard etc, only to make a 180 on all of them with HTML5 because in the end the web itself had final word. – Hyp

Answer 1

As discussed in the comments, this is a bogus warning.

As you point out yourself, there is no generic font family that is suitable as a fallback for an icon font - nor can there be, as icon fonts are not standardized.

The relevant spec (CSS Fonts Module Level 3) only lists the following generic families:

• serif
• sans-serif
• cursive
• fantasy
• monospace

None of these is suitable - as they are all explicitly not intended for icon/picture fonts.

So you should probably find a way to suppress the warning. Ideally, the system would allow you to add a list of fonts that the warning should be suppressed for (such as icon fonts). Otherwise, you'll just have to suppress the warning entirely.

---

Side note: Fallback fonts are only really necessary if you want to use a font that is installed on the user's computer - such as standard Windows fonts like Arial. In that case you need a fallback, because you cannot be sure what the user has installed.

If you use a web font that the browser can download, there should never be a need for a fallback font. It is still nice to include in case the font download fails, but IMHO not as important.

Manzo

There is emoji. And you could consider emojis as the one and only standardized icon set we have. Every device/app that supports Unicode supports the Unicode emoji set which is growing steadily and getting ever more useful for web design. Check out the font Noto Emoji to see what I mean. I believe emoji will be the standard icon set and as such using emoji as generic fallback makes total sense to me. – Hyp

@StijndeWitt: Well, yes, but no ☺. First, "emoji" is from CSS Fonts Module Level 4, which is quite new. AFAIK, no current browser even supports it. Additionally, "emoji" is for fonts which contain emojis, while icon fonts usually contain arbitrary icons (unless your icon font is really an emoji font). – Manzo

Since the entry in the font stack is for fallback purposes only, whether it is supported yet or not is not really relevant. It will not be selected anyway. And at the same time it is a standardized and semantic way of communicating 'this is a font intended for emoji'. Which is not 100 percent correct, but the closest to 'this is a font for icons' that we can come with the current standard. I wish w3C would give things like icons and user interface elements some more love but they don't unfortunately. – Hyp

Answer 2

You can add "fantasy":

.my-icon {
  font-family: 'my-icon-font', fantasy;
}

Raguelragweed

Interesting, but why? – Equiangular

Because for me this is the best valid option. The other option might be 'emoji'. developer.mozilla.org/en-US/docs/Web/CSS/font-family – Raguelragweed

Sorry, but that's plain wrong. The CSS spec explicitly says that "fantasy" is for "decorative or expressive fonts that contain decorative or expressive representations of characters", and that "These do not include Pi or Picture fonts which do not represent actual characters." There is no suitable fallback for icon fonts. – Manzo

@mtonev, your justification should be in your answer, not in a comment. – Berga

@Manzo I agree that fantasy is not the best choice. But I think emoji covers icons pretty well. – Hyp

Futhermore, there simply is no 'that is plain wrong' here. The fact is that the current standard gives us no way to communicate our true intent, whih is to say that this is a font for icons. When we as web developers face such gaps, we need to be inventive. Most standards development is driven by regular web devs like you and me. The w3c just writes down and formalizes the stuff that we come up with. – Hyp

Answer 3

@mtonev

emoji - Fonts that are specifically designed to render emoji. https://developer.mozilla.org/en-US/docs/Web/CSS/font-family

The 'other option' is also not suitable. And as similar as emojis and icons may seem: emojis have a unicode representation and iconfonts are just a collection of images

learn more: https://www.sitepoint.com/icon-fonts-vs-svg-debate/

Phenology

Who or what are you quoting there? What is 'other option'? What is your solution? Please see How to Ask and take the tour. – Berga

This should be the accepted answer. emoji is indeed the most sensible fallback for an icon. – Hyp

Is this supposed to be an answer? If yes, that what is the answer? It seems to be part of a discussion. Could you edit to add context? – Manzo

@StijndeWitt if you think this should be the accepted answer, are you willing to shape it up into a proper answer? – Yarbrough