认真地，不要使用图标字体-云四

图标无处不在。这些 “小奇迹工作者”（如约翰 · 希克斯（John Hicks）所描述的）帮助我们在设计和构建的界面中增强了意义。他们在网页设计中的知名度从未像现在这样大。象形图的简洁性和多功能性使其特别适合各种大小的显示器。

但是网络上的图标面临着很多挑战。为准备每种预期的显示器尺寸和颜色，它们非常耗时。当高分辨率显示器投放市场时，与它们经常伴随的文字相比，图标看起来分辨率特别低并且显得块状。

因此，毫无疑问，图标字体如此受欢迎。通过显示的图标@font-face与分辨率无关，并且可以按照我们期望文本的所有方式进行自定义。当然，将图标作为字体交付绝对是一种技巧，但它也很有用，用途广泛，甚至可能有点有趣。

但是现在我们必须停止。现在是时候让图标字体传递给 Hack Heaven 了，在这里他们可以与基于表的布局，防弹圆角和可伸缩 Inman Flash 替换一起嬉戏。这就是为什么…

大多数辅助设备都会大声朗读通过 CSS 插入的文本，并且许多 Unicode 字符图标字体所依赖的字体也不例外。在最佳情况下，您的 “收藏夹” 图标被大声读出为 “黑色喜欢的星星”。更糟糕的情况是，它被读为“无法发音” 或被完全跳过。

许多阅读困难的人发现将网站的字体换成 OpenDyslexic之类的东西很有帮助。但是图标字体也被替换了，这给用户带来了令人沮丧的体验。

大多数时候，我们依靠自动化工具来选择将哪些 Unicode 字符分配给哪个图标。但是 Unicode 也是我们心爱的表情符号所居住的地方。如果您不小心，它们可能会以令人困惑（尽管很搞笑）的方式重叠。我最喜欢的示例：Etsy 的 “四颗星和一匹马” 错误。最近，我们自己的杰森 · 格里斯比（Jason Grigsby）在 ESPN 的网站上遇到了随机的拳头颠簸。

当您的图标字体失败时，浏览器会像对待其他字体一样对待它，并将其替换为后备字体。在最佳情况下，您已经精心选择了后备角色，并且仍然加载看起来怪异但易于交流的内容。在最坏的情况下（并且更常见），用户会看到完全不协调的内容，通常是可怕的 “缺失字符” 字形。

自定义字体不应该成为任务关键资产。他们总是失败。一眼看过Bootstrap 与图标相关的问题，也就不足为奇了为什么他们要从下一版本中完全删除它们。

更糟糕的是，许多用户将永远看不到那些字体。Opera Mini 的，频繁的对手的 iOS Safari 浏览器在全球的使用统计与数以百计的全球数百万用户，不支持@font-face在大多数情况下。如果您要支持 Opera Mini， Opera 建议避免使用图标字体。

浏览器提示字体以提高可读性的方式从来都不适合我们的自定义图标，并且支持调整行为的方法无处不在。

多色图标甚至更糟。叠加多个字形以实现效果的技术非常有用，但是结果通常看起来像是它们的打印配准未对齐。

“但是泰勒，” 我听到你说。“您完全忽略了Filament Group 的 Bulletproof Icon 字体，包括功能测试和明智的，由内容驱动的后备解决方案。”

而且你是对的。这些技术很棒！如果您使用的是图标字体，则一定要遵循他们对这封信的建议。

但是您可能不会。

您可能要做的就是采用您选择的框架捆绑的任何东西，或者放入一些可以立即使用的大量免费图标字体。您不会修改它们的开箱即用方式，因为这真的很难确定优先级，尤其是当它们在您的显示器上看起来很漂亮而几乎没有任何努力时。

或者，也许您将做这些工作，设计和管理自定义图标字体，仔细选择 Unicode 字符，记录并宣传以适当的后备以可访问的方式实现图标的重要性。然后有一天，戴夫（Dave）忘了在他添加的标志性按钮上添加一个备用图像（顺便说一句，看起来不错），罗伯塔（Roberta）在她的相关 “拉取请求” 中重复使用了该图像，在不知不觉中，您的应用就变成了脆弱的应用，乱糟糟的荒原再次出现。

这些示例不是假设的（尽管名称已更改以保护无辜者）。我已经看到它们发生在多个组织中，所有这些组织都是以最好的意图开始的。

SVG 是真棒的图标！这是一种矢量图像格式，具有对 CSS，JavaScript，可重用性，可访问性等的可选支持。它是为这种事情而做的。

但是我听到很多借口，说明团队为何不使用它，即使是在全新项目中也是如此。这里有一些…

他们完全可以。甚至还有诸如svg-sprite和IcoMoon 之类的非常好的工具，可以帮助实现该过程的自动化。

通常，当我听到此消息时，团队会将单个二进制图标字体与多个未压缩的 SVG 文件进行比较。当您优化 SVG，将可重复使用的SVG组合到精灵中并通过主动 Gzip 压缩或嵌入式页面内交付时，差距会大大缩小。

有时候，我听说包含数百个图标时差距仍然很大。这就引出了一个问题：为什么在每个页面上都包含数百个图标？

让我们比较一下：

 <span class="icon icon-search" aria-hidden="true"></span>
<svg class="icon">
  <use xlink:href="path/to/icons.svg#search"/>
</svg>

SVG 标记仅比某些空的，ARIA 隐藏的<span>元素更冗长，并且更具描述性和语义。

As of this writing, global support for SVG is up to 96%… 4% higher than the same stat for @font-face. Plus, SVGs are way more accessible and their fallbacks are much more straightforward.

“The framework we chose already has an icon font.”

If your framework told you to jump off a bridge, would you?

I was in school when the Web Standards movement hit critical mass. While the majority of my instructors saw the merits of semantic markup and embraced it wholeheartedly, one passionately held out. “Table Guy” argued that no layout tool could usurp <table>, that it was inherently better-suited for crafting grid-based designs. He boasted of how quickly and easily he could achieve the “Holy Grail” layout with his trusty table cells. He cited the wealth of cross-browser inconsistencies that continued to plague CSS.

Table Guy and I kept in touch. Today, he freely admits he was wrong about CSS. He feels embarrassed to have been so married to a technique that was so clearly misappropriated in hindsight.

If you won’t stop using icon fonts for people with screen readers, people with dyslexia, people with browsers that don’t support @font-face, people who randomly didn’t load the icon font once for some reason, or designers who just want their icons to look right on-screen…

Then do it for yourself. Don’t be Table Guy.
https://cloudfour.com/thinks/seriously-dont-use-icon-fonts/