Web 版式和 @font-face 简介

目录

• 安全使用：Web 版式的开端
• 超越 Web 安全字体：@font-face
• 使用 Web 字体的挑战
• 延伸阅读

随着大量支持 CSS3 @font-face 的浏览器诞生，Web 上的版式向前发展了一大步：您最终可以在网页中使用真实的字体，而不会求助于以来图像、Adobe Flash 或其他基于非文本的技术的解决办法。但这个新的 Web 版式时代也带来了新的法律、技术和设计挑战。本文介绍我们如何实现 Web 版式，如何以可客户所涉及到的新挑战的方式使用 Web 字体，为您提供在 Web 设计和开发项目中成功应用已存在 1 世纪的版式原则的自由。

安全使用：Web 版式的开端

经过在印刷媒介中数百年的磨砺，版式的设计现包含一些节本的准则，比如使用对比、重复、对齐和近似性来明确且个性地传达含义，在品牌影响力下保持合法性。这些准则在Web 上与在其他任何地方一样重要——毕竟， Web 设计的 95% 都关乎版式。甚至可以说，版式在 Web 等交互式媒介中甚至更加重要，其中由于文本可能是可单击的并具有行为，所以它不仅仅是 _ 内容 _，它是 _ 用户界面 _。

总之，拥有选择正确的字样的能力是关键。在如今由各种不同的搜索引擎、设备和残疾人技术访问动态、不断更新的网站的世界里，以可访问、可维护和基于标准的方式选择正确的字样是一项必不可少的能力。

在 Web 的大部分历史中，这个圣杯都遥不可及。

尽管版式设计的悠久历史催生了书签中字样，但当 Web 诞生时，在这种新媒介中工作的设计人员几乎无法选择要使用的字样。例如，1993 年，第一个图形 Web 浏览器 NCSA Mosaic 仅包含单一的、默认的字体（参见图 1）。

图 1. NCSA Mosaic 1.0 提供了极其有限的版式控制。图片来源：NCSA/University of Illinois

Web 安全字体

这一情形在接下来的 15 年中仅有细微的改观，因为所谓的“Web 安全”字体集到 2008 年在增长到大约 18 个（参见图 2）。Web 安全字体是预先安装在主流个人计算机操作系统中的系统字体的子集——类似于最小公分母。因为 Web 设计人员和开发人员知道他们网站的所有访问者都至少拥有这 18 种字体之一，所以它们可通过 CSS 中的 font-family 属性引用它们，从而在网页中安全地使用它们。然而，考虑印刷设计领域可用的数千种字体，能够使用 _18_ 种字体仍然是很糟糕的情景。差异化地表示、品牌化、找到适合工作的正确字样的能力仍然不容乐观。

图 2. 到 2008 年，“Web 安全”字体集增长到了大约 18 种。（图片来源：所有 Windows 版本和 Mac 等效版本的常见字体。）

解决办法：将文本用作图像、脚本或对象

围绕这些限制，一些设计人员开始依靠各种技巧和解决办法来推进Web 版式发展。或许这些方法中最常见的是使用图像来在渲染非Web 安全字体中的文本。这使得可以在网页中使用任何字体，但这样做具有重大的成本：因为文本陷入在图像中，它不可选择、搜索、翻译或供使用残疾人设备的人访问，与正常的HTML 文本不同。CSS 图形替换等技术可解决这些问题，使用CSS 将图像放在底层文本上，底层文本实际上位于页面的HTML 源代码中，因此可供搜索和访问，但可选择性和可翻译性问题仍然存在。而且，对于频繁更改的文本元素，比如新闻网站的头条新闻，此技术会带来在文本更改时创建新图像所需的维护成本，除非网站的开发人员设置了一种服务器端机制来动态生成这些图像。基本原则是：使用图像渲染文本能够实现更丰富的Web 版式，但它采用笨重方式的复杂性通常超过了收益。这是一次大胆的努力，但最终不是发展的最佳方式。

其他解决办法，比如基于JavaScript 的 Cufón 和 typeface.js ，会自动化画布或 VML 元素中的文本的渲染。尽管这最大程度减少了使用图像渲染文本所带来的维护和设置成本，但它仍然导致了渲染的文本给人感觉不是 _Web__ 原生的 _：文本不可选择或调整。另外，使用此技术来渲染大量文本（例如，包含许多段略的正文）可能对性能带来负面影响。

另一种技术将字体样式的文本渲染为某种与 HTML 文本不同的东西，使用 Flash 代替画布或 VML。在此方法中，设计人员将一个字体嵌入到一个 Flash 对象中，将它应用于该对象中的文本，然后通过 Flash 平台内置的文本渲染引擎渲染该对象。这无疑会带来漂亮且高效的版式，但它也可能导致使用图像或其他非文本元素渲染文本的方法固有的一些相同问题。但是，更重要的是这样一个事实，来自苹果公司越来越流行的 iOS 平台不支持 Flash。这意味着 iOS 设备（比如 iPad 和 iPhone）的用户不会从此方法所实现的漂亮版式获益——或者，更糟的是，它们完全不会看到该文本。

超越 Web 安全字体：@font-face

正确的发展道路非常简单，它所基于的是设计标准的、构建块式的 Web 技术 HTML 和 CSS 来以作者定义的样式联合呈现内容的方式。确实如此：它就是使用一种名为 @font-face 的 CSS 功能，通过链接到一个字体文件（而不是通过引用预先安装的系统字体）来定义一个字体集，然后通过 CSS 中的 font-family 属性引用该字体，从而将它应用于网页元素，这非常类似于您应用 Web 安全系统字体的方式。

这种基本的 CSS 机制的工作原理如下。首先，您使用一个 @font-face 声明定义一个字体集，使用 font-family 描述符为它提供一个名称，然后使用 src 描述符指向包含字体本身的文件：

 
@font-face { 
   font-family: 'Awesome Font'; 
   src: url('awesome-font.ttf'); 
} 

这里，通过链接到一个名为 wesome-font.ttf 的字体文件，定义了一个名为 Awesome Font 的字体集。

然后，在您的 CSS 中，使用 font-family 属性将该字体应用到一个 HTML 元素，非常类似于您对 Web 安全系统字体所做的：

 
h1 { 
   font-family: 'Awesome Font'; 
} 

这里，Awesome Font 字体集（前面使用 @font-face 声明定义）应用于 1 级标题。

以这种方式渲染的文本具有正常的 HTML 文本样式，使用一种作者定义的字体集，而不是默认的系统字体集。这意味着此方法避免了基于非文本的解决办法的问题：文本是可搜索、可选择、可调整、可访问和可轻松维护的。

它的核心其实就是 CSS @font-face。这种基本机制是由 Web 标准机构万维网联盟在二十世纪 90 年代晚期定义的。不幸的是，由于那个时代的浏览器战争和其他因素导致了不一致的实现，它从未被充分利用——直到最近。到 2009 年，所有主要 Web 浏览器都支持 @font-face，很快 iPhone 和 iPad 上的移动 Safari 浏览器也提供了支持。朝 Web 安全字体发展的正确道路最终被采用。

但简单、开放、基于标准的 @font-face 质量带来了一个新问题。以销售字体为生的人担忧，一旦您可以将一个字体文件链接到网页中（因此向它公开一个链接），很难保护该文件不被盗窃。这种担忧阻止了大多数商业创建者允许将它们的字体用于 Web 字体。

这正是第一批托管的 Web 字体服务（包括 Typekit ，我合作创建的服务）使用解决方案介入的地方，这些解决方案允许设计人员使用字体作为 Web 字体，同时仍然保持这些字体远离未授权的使用。

这是 Typekit 中的工作原理：作为设计人员，您购买 Typekit 的字体库的订阅，选择您希望使用的字体，指定您希望在其上使用这些字体的网站。Typekit 然后为您提供一个 JavaScript 代码片段以添加到您的 HTML 页面的标题元素中。当用户访问您的网站时，该 JavaScript 从 Typekit 的系统请求字体。如果请求来自您向 Typekit 注册的网站，字体将使用标准 CSS @font-face 动态地注入到页面中；如果不是，字体会被拒绝。您向 Typekit 支付字体使用费用，Typekit 然后与字体所有者分享收入。

当然，许多 Web 开发人员知道都知道这种保护方法（称为 _ 引用方检查 _）可使用简单、广泛使用的命令行工具来欺骗一个引用方而轻松规避。这正是 Typekit 通过一种方式修改字体文件来保护字体的原因，这种方式不会更改它们渲染或执行的方式，但将使它们无法安装在操作系统中。这样，即使您绕过了引用方检查或者您从浏览器缓存中挖走了这些字体，它们仍然无法在 Adobe Photoshop 等应用程序中安装和使用，这是许多传统创建者在业务中提供的服务，以及因此而担忧要保护的服务。这个额外的防御层尽管仍然可被某个拥有正确的字体编辑软件和专业技能的人破坏，但已足以阻止字体的随意误用，并且它已使许多字体铸造上习惯于允许它们的字体通过 Typekit 用作 Web 字体。

当然，Typekit 不是唯一一个托管的商用 Web 字体服务。该领域现在包含许多选项，包括 Kernest 、 Fontdeck 、 Fonts.com Web Fonts 、 WebINK 、 FontsLive 、 WebType 等。尽管在功能、选择和价格上不同，但每项服务都具有相同的基本功能：它们托管授权用于 Web 用途的商用字体文件，通过 CSS @font-face 向 Web 设计人员提供访问它们的权限。

某些创作者和 Web 服务，包括 FontFont 、 Process Type Foundry 、 Fontspring 和 Monotype 的 Fonts.com Web Fonts ，现在也在某些情况下提供了可供您下载并自行托管的 Web 字体，而无需依赖于托管的第三方服务。这常常可以结合一种名为 WOFF 的新兴标准 Web 服务格式来使用，后者在本质上是一个围绕字体文件的包装器，使该字体无法安装在操作系统中，但仍然可在支持该格式的浏览器中用作 Web 字体。但是，不是所有广泛使用的主流 Web 浏览器版本都支持 WOFF，所以，取决于字体和创建者 / 服务，使用托管的 Web 字体服务可能仍然是向您网站的访问者所使用的大部分浏览器提供字体的唯一方式。

使用Web 字体的挑战

使用托管、商用的Web 字体服务以及WOFF——更别提免费的Web 字体来源，比如 Font Squirrel 和 Google Web Fonts——Web 字体授权的问题已经解决。超 Web 上的富版式发展的最佳道路已清除了障碍。

但是，不幸的是，这仍然不是故事的结尾。

Web 字体格式和浏览器支持

事实证明，Web 字体具有许多不同的格式，并且毋庸置疑，各种 Web 浏览器支持这些格式的不同子集（参见图 3）。

图 3. 主流 Web 浏览器每个都支持不同的 Web 字体格式。

这带来了一项技术挑战。为了支持所有主流 Web 浏览器，一个 @font-face CSS 声明实际上无法像前面提到的那么简单：

 
@font-face { 
   font-family: 'Awesome Font'; 
   src: url('awesome-font.ttf'); 
} 

相反，它必须看起来更像这样：

 
@font-face { 
   font-family: 'Awesome Font'; 
   src: url('awesome-font.eot'); /* IE9 Compat Modes */ 
   src: url('awesome-font.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */ 
   url('awesome-font.woff') format('woff'), /* Modern Browsers */ 
   url('awesome-font.ttf') format('truetype'), /* Safari, Android, iOS */ 
   url('awesome-font.svg#svgFontName') format('svg'); /* Legacy iOS */ 
} 

这就是所谓的 Fontspring @font-face 语法，它是最初的 Bulletproof @font-face 语法的最新版本。结合使用 @font-face 格式描述符和各种附加编码，这种语法开发用于诱导浏览器使用它们支持的最佳的（或者在某些情况下是唯一的）Web 字体格式。不幸的是，事实证明最初的语法无法防弹（Bulletproof）。经过各种迭代，它必须不断更新来克服各种问题，比如对移动支持和最新浏览器版本（比如 IE9）支持的限制。

但是，这里重要的不一定是了解此语法的每次迭代的细节，而是认识到 CSS 语法需要使用 Web 字体的变化，因为浏览器领域在不断演化，也因为 Web 字体社区在掌握越来越多的浏览器支持和字体技术信息。这意味着您一定要在实现启用了 Web 字体的网站之后继续定期测试它们，尤其是当浏览器供应商发布新浏览器版本时。这也是考虑使用托管 Web 字体服务的一个不错理由，其中，选择向哪些浏览器提供哪种 Web 字体格式的逻辑可以不用您操心了，而且理想情况下，可由 Web 字体服务继续更新。无需亲自维护一种复杂并可能不友好的 @font-face 语法，您可以将这种复杂性抽象到某些东西背后，就像这么简单：

 
<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script> 
<script type="text/javascript">try{Typekit.load();}catch(e){}</script> 

这是一个用于在网站上启用 Typekit 的示例 JavaScript 代码。其他托管的 Web 字体服务提供了类似的简单机制，有些服务使用 JavaScript 提供 @font-face 字体，以控制加载行为（下面将介绍更多收益信息），其他服务仅依赖于 CSS。

无论您选择哪条路径——托管您自己的 Web 字体文件并维护使用它们所需的 @font-face 语法，或者将该工作外包给一个托管的 Web 字体服务——好消息是可以导航 Web 字体格式和浏览器支持的复杂性，因此最终打开通往丰富且不断增多的字样选择的大门。

闪烁的无样式文本

使用 Web 字体的另一项挑战是处理一种称为“闪烁的无样式文本”或 FOUT 的现象。

一个 Web 字体是一项远程资源，就像图像或视频一样，并且这意味着它必须下载。那么，在下载 Web 字体时 Web 字体样式文本应该发生什么？各种浏览器会采取不同的方法。

IE9 和 Firefox 等基于 Mozilla 的浏览器的一些版本在等待 Web 字体下载过程中，将使用一种备用字体显示文本，如图 4 所示。在此示例中，第一行文本在其 font-family 堆栈中有一个 Web 字体，后面是一个 Web 安全的备用字体。第二行文本仅包含 Web 安全的备用字体。在等待 Web 字体下载的过程中，Firefox 会使用备用字体公式渲染这两行。

图 4. 这里，Firefox 在 Web 字体加载期间使用一种备用字体显示 Web 字体样式的文本。

下载Web 字体之后，Firefox 将第一行切换为使用Web 字体渲染（参见图5）。

图5. 这里，Web 字体完成加载后，Firefox 将Web 字体样式文本从一种备用字体切换为Web 字体（Rosewood Std from Adobe）。

这可能是一种不和谐的体验，导致颤动和布局移动，尤其是在Web 字体的指标（比如光学垂直/ 水平大小、默认行高等）与备用字体的指标不同时。这就是“闪烁的无样式文本。”

相反，Chrome 或Safari 等基于WebKit 的浏览器在等待Web 字体下载期间会隐藏Web 字体样式文本，在布局中为它留出空间，如图6 所示。这是与前面相同的两行示例，但可以看到，第一行不可见。

图6. 这里，在加载Web 字体期间，Safari 隐藏了Web 字体样式文本，在页面的布局流中为文本留出了空间。

当Web 字体下载后，Safari 使该文本可见，并且它已使用Web 字体渲染（参见图7）。

图7. 这里，在Web 字体完成加载后，Safari 使Web 字体样式文本可见。

这种体验更加流畅，可能是许多用户和设计人员首选的。

幸运的是，您无需等待并接受不同浏览器之间的这种不一致性。您可以使用 WebFont Loader （Typekit 与 Google 合作开发的一个 JavaScript 库）控制这些浏览器之间的区别。作为开源项目发布，它兼容各种托管的 Web 字体服务，以及甚至您自己的自托管 Web 字体。

注意：如果您使用 Typekit，您可以利用 WebFont Loader，而无需加载额外的 JavaScript 文件，因为它已经构建到您放入页面中来启用 Typekit 字体的 Typekit JavaScript 代码中。

WebFont Loader 通过 JavaScript 加载字体，以便能够确定字体何时开始加载，何时完成加载，以及它是否将完全加载（比如由于它是使用一个不支持 Web 字体的旧游览器请求的）。

对于这些事件中的每一个（每个状态），WebFont Loader 动态地将一个类名添加到包含页面的 HTML 元素中。这些类用于下载字体时的 wf-loading，用于字体完成加载时的 wf-active，以及用于字体不会加载时的 wf-inactive。您可以在您的 CSS 中使用这些类在每个状态期间更改页面元素样式，如此模式中所示：

 
<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script> 
<script type="text/javascript">try{Typekit.load();}catch(e){}</script> 
<style type="text/css"> 
   .wf-loading { 
       /* styles to use when web fonts are loading */ 
   } 
   .wf-active { 
   /* styles to use when web fonts are active */ 
   } 
   .wf-inactive { 
   /* styles to use when web fonts are inactive */ 
   } 
</style> 

这对 FOUT 现象有何帮助？您可以使用类在字体加载期间隐藏文本，但仍然在布局中为该文本留出空间。这将在所有 Web 浏览器上模仿 Safari 的行为。以下是需要的代码：

 
<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script> 
<script type="text/javascript">try{Typekit.load();}catch(e){}</script> 
<style type="text/css"> 
   .wf-loading h1 { 
       visibility: hidden; 
   } 
</style> 

翻译为人类语言，此示例表明“当一个 h1 包含在 wf-loading 的范围内时，隐藏它的“可见性”。”这样会在加载字体时隐藏文本，在页面的布局流中为它留出空间。然后，当字体加载后，这个 CSS 就不再适用（因为 WebFont Loader 在那时删除了 wf-loading 类），所以该文本然后就变得可见了。

这会将 WebKit 更流畅的字体加载体验带给所有浏览器，使 FOUT 成为过去。

Web 字体渲染

使用 Web 字体的另一个挑战是渲染的问题。如果您以前使用过 Web 字体，您可能已渲染过，为什么相同的字体可以在不同浏览器中渲染出如此不同的效果？或者为什么两种不同的字体，以相同的字号渲染，可能得到如此不同的可读性水平？

一种字样是一种想法——它是一种可缩放大小的形状——并且作为一种想法，它具有无限的分辨率。在计算机屏幕上渲染该想法，意味着在一个相对低分辨率的像素网格上这么做。这可能导致一些字样出现问题，尤其是这些最初为打印而设计的字体，其中分辨率并不像在屏幕上一样是一个受限的因素。关于事情如何出错的信息，请参阅图 8 左侧的“O”，这是字样设计人员 Tim Ahrens 编写的关于此主题的优秀博文中的一个示例。这里，“O”字符的右边恰好落在单列像素上，这是由字符的总体形状和它在网格上的位置导致的。但是，“O”的左边落在两列像素上。这使渲染的字符看起来不对称，当与该字体的许多其他字符的类似方面相结合呈现时，这可能影响具有此字体样式的文本的可读性。

图8. 左侧的“O”看起来不对称，因为它的右边仅落在一列像素上，而它的左边落在两列上。从右侧的“O”上显示的微调（hinting）可以看出，可通过指定一个字形的相应部分应该始终在宽度上始终具有相同数量的像素，从而改善此情形。（图片来源：Tim Ahrens。）

幸运的是，一些在首次用于Web 文本而不是印刷文本时显示出类似问题的字体已通过一项称为_ 微调_ 的技术进行了改进，针对在像素网格上更好地渲染而优化。通过字样设计人员使用字体编辑软件对字体进行加强，微调是一组提供给文本渲染引擎的关于在出现这类问题时因如何做的说明。在图8 右侧的“O”中，您可以看到微调表示为字形每一边上的链接。这些微调指定，字形的某些对应部分始终应该在宽度上具有相同像素数量，无论字形在落入像素网格时如何自然地形成。这可以显著改善此字体中的文本集的可读性，尤其是在更小字号上和在老版Windows 上运行的浏览器中。（如果您对更多相关机制感兴趣，Tim Ahrens 的 A closer look at TrueType hinting提供了一些有趣的细节。）

最后一个事实（一些浏览器和操作系统需要更多地借助微调的帮助）与 Web 字体渲染的另一个现状相关：各种浏览器和操作系统组合所使用的不同文本渲染引擎会不同地渲染文本，有时这种区别很细微，有时却很明显。这使得了解您使用的一种字体如何在您关注的浏览器中实际渲染至关重要：字体会从在任何这些浏览器中从微调获益吗，如果会，它是否经过了微调？字体是否能够在这些浏览器的每一个中以您将使用字号良好地渲染？在获得这样的问题的答案时，会在 Web 设计和开发中添加一个新的跨浏览器测试层——以及在设计项目的 _ 开头——_ 它可以避免在项目晚期出现意外的渲染效果，如果您必须回溯到字样选择阶段，这可能浪费大量的工作。

如果使用 Typekit 字体，您可以使用 Typekit 的 Browser Samples 功能查看您考虑的字体如何在 Typekit 支持的每个浏览器和操作系统组合中渲染，从而节省时间和资源（参见图 9）。

图 9. Typekit 的 Browser Samples 工具显示字体如何在 Typekit 支持的每个浏览器和操作系统组合中渲染。

简单来讲，在您的设计流程中尽早留意 Web 字体渲染，将有助于您从可用的 Web 字体选择正确的字体。但是如果您必须使用无法在您关注的所有环境中良好渲染的 Web 字体，您仍然有选择。您可以考虑使用基于 CSS 或 JavaScript 的浏览器，向无法良好地渲染您喜欢的字体的浏览器和操作系统组合中显示一种 Web 安全备用字体。如果您能够访问各种在线格式的字体，您也能够将最佳的分级显示格式分类发送到某些浏览器和操作系统组合（因为 Typekit 和其他创建者已在它们的托管服务中这么做）。您甚至可以与字体的设计人员合作，或者与其他精通微调的设计人员合作，针对您希望在 Web 上使用字体的每种方式对它进行优化。像这样的高级方法演示了实现高品质 Web 字体渲染时的可能性——但是，在许多情况下，当您可尽早自由选择一种渲染良好的字体时，您将能够避免这种类型的技术工作，专注于 _ 使用 _ 字样设计，而不是 _ 设计 _ 字样。

延伸阅读

由于上面讨论的复杂性，使用 Web 字体看起来很艰难，但它们可能很简单。现在您已知道如何合法地获得 Web 字体，如何以一种可维护的方式将它们包含在您的网页中，如何控制不同浏览器之间的字体加载区别，以及如何理解 Web 字体渲染，以便为您的设计选择正确的字体，您拥有了参与 Web 版式中的持续复兴所需的知识，而没有头痛。所以请全情投入，出色发挥！以下是一些有用的资源，可在您学习的过程中添加到您的工具箱中。

可从以下链接获得 Web 字体：

• Fontdeck
• Fonts.com Web Fonts
• FontsLive
• Font Squirrel
• Fontspring
• Google Web Fonts
• Just Another Foundry
• Kernest
• The League of Moveable Type
• MyFonts Webfonts
• Process Type Foundry
• Typekit
• Typotheque
• Web FontFonts
• WebINK
• WebType

使用 Web 字体：

• Bulletproof @font-face 语法
• Fontspring @font-face 语法
• Lettering.js
• WebFont Loader

文章、教程和讨论：

• 关于版式和 web 字体的 A List Apart 文章
• 适用于 Web 的版式样式元素
• 不错的 Web 字样
• 版式：Adobe 字样团队博客
• Typophile

+

本作品依据 Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License 授权。与本作品中包含的代码示例相关，超出本许可范围的权限可在 Adobe 上找到。

查看原文： Introduction to web typography and @font-face