《响应式Web设计实践》一2.2 字体大小

简介:

本节书摘来异步社区《响应式Web设计实践》一书中的第2章,第2.2节,作者: 【美】Tim Kadlec 译者: 侯鸿儒 责编: 赵轩,更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.2 字体大小

响应式Web设计实践
要想让你的设计拥抱Web的流动性,那就意味着在你的设计中要能够灵活地改变字体大小。你可以在Web上使用任意单位来设置字体大小,但主要的方法不外乎三种:像素、em,还有百分比。

2.2.1 像素

长期以来,像素一直都是人们喜欢使用的字体大小单位,其原因很简单:无论浏览器如何设置字体大小,你都能对其进行精确的控制。如果你把字体设置为18px,那么每个浏览器都会将其准确地显示为18px。

但这样的掌控是要付出一定代价的。对于初学者而言,虽然使用像素作为字体大小单位时不需要考虑级联——父元素的字体大小对子元素没有影响,但这也意味着当你想让某些文本以不同的大小显示时就需要对它们逐一设置。这对于维护来说非常不利,因为当你想增大所有字体时,你就不得不去逐一修改每一个值。

更重要的是,以像素为单位的字体存在着潜在的可访问性问题。所有主流的浏览器都允许用户放大或缩小页面,浏览器对该操作通常有两种实现方式。

第一种方式是简单地将页面上所有的东西都放大,所以当访问者放大页面时,包括文本在内的所有的元素都会变大。在这种情况下,无论字体大小使用哪种单位,都允许用户进行缩放(图2.2)。

另外一种方式是浏览器只调整文本的大小,页面上其他元素则保持不变。长期以来这都是常见的浏览器实现方式,并且现在仍有一些浏览器采用这种方式实现缩放功能。

而且不幸的是,以像素为单位的字体在老版本的IE中是无法实现缩放的。这意味着那些使用IE9之前的、字体被设为默认大小的IE浏览器(或者在最新版中启用了字体默认大小的浏览器)的用户,是不能调节你的页面中字体的大小的。


2

无法调整字体大小的问题也同样出现在很多较老的、在触摸屏出现之前就已经存在的设备上。有时所有的页面内容都不能缩放,在这种情况下,虽然字体还是同样的大小,但部分页面也许就不太适合人们阅读了。

浏览器能够调整文本的能力给了用户更多的控制权,另外作为浏览器本来就应该实现的功能,这样做也可以提高站点的可访问性。因为对于某些访问者来说,当字体大小小于某一数值时,就会给他们的阅读造成障碍。所以允许用户增大字体就意味着他们可以继续享用你的站点里的内容。

用像素指定字体大小依然不是一种对未来特别友好的方式。由于不同的设备有着不同的屏幕大小和像素密度,因此以像素为单位的字体也许在这台设备上看起来不错,但在另外一台设备上看起来也许就会要么太大、要么太小了(本章后面“默认字体大小”对此会做进一步的讨论)。使用像素作为字体大小的单位,是与Web的灵活性原则背道而驰的做法。

2.2.2 em

使用em作为字体大小的单位是一种更加流行、更具灵活性的方法 。正如前面介绍过的那样,1em等于默认的字体大小,例如,如果内容的字体大小是16px,那么:

1em = 16px

2em = 32px

em可以跨浏览器进行缩放,而且它们也是级联的——这既可以是好事,也可以是坏事。从简化维护的角度来看这是好事,因为这样相对地指定元素的字体大小,意味着你只需要调整初始化时的基准,其余部分就会自动地进行调整,而且是按比例调整的。

但级联也会使事情变得复杂。例如,考虑一下下面的HTML:

<body>
     <div id="main">
         <h1>Question One <span>Please choose an answer from below.
            </span></h1>
<p>In which book did H.G. Wells write: "Great and strange ideas 
  transcending experience often have less effect upon men and women than smaller, more tangible considerations."</p>
     <ol>
          <li>The Invisible Man</li>
          <li>The War of the Worlds</li>
          <li>The World Set Free</li>
     </ol>
</div>
</body>

其对应的CSS如下:

body {
     font-size: 16px; /* base font size set in pixels */
}
h1 {
     font-size: 1.5em; /* 24px / 16px */
}
span {
     font-size: 1em; /* 16px / 16px */
}

在上面的例子中,字体基准被设置为了16px,h1元素的字体大小为1.5em,即24px。我们想把span元素的字体大小设置为16px,所以我们将其设置为1em。但问题在于上下文环境变了:基准已经不再是body字体的16px了,而是h1元素的24px。因此span元素的字体大小将会显示为24px,而不是我们期望的16px。

所以我们需要调整span元素的font-size来缩小它:

span {
     font-size: .666666667em; /* 16px / 24px */
}

要试着结构化你的CSS和HTML,并保持字体大小的可预测性。例如,如果你的内容部分使用了基准字体大小,并且只改变了标题元素的大小,那么你就可以避免这些问题了。类似地,如果你的HTML是经过精心设计的,你也可以很容易地通过后代选择器来解决这些问题。

后代选择器
一种CSS选择器,用来匹配特定元素的子元素。

2.2.3 百分比

和以em为单位的字体一样,以百分比为单位的字体也是可缩放的,而且也是级联的。另外与em类似的是,如果基准字体大小是16px的话,那么100%相当于16px,200%相当于32px。

虽然从理论上讲,百分比和em没有太大的区别,而且em逐渐成为了Web中更受欢迎的字体度量单位,但其实这其中并没有什么技术上的原因。只有当出于em直接与文本大小相关的考虑时,使用em才更有意义。

然而,承蒙众多用户喜爱的IE浏览器,却在显示以em为单位的基准字体时会有问题。如果基准字体是以em为单位的,那么IE会夸大实际应当调整的字体大小。假如你把基准字体大小设置为了1em,并且把h1元素的设置为了2em,在绝大多数的浏览器中,h1元素会像我们预料的那样显示:它们会变大两倍,但在IE中它们会变得更大。要解决这个问题,我们得感谢下面这个小小的漏洞。

你可以通过在body元素上以百分比为单位指定基准字体大小来绕过这个问题。

body {
     font-size: 100%;
}

引人注目的是,在大多数浏览器和设备中,默认的字体大小都是16px(后面专栏中有更多的相关信息)。通过将body的字体设置为100%,你就可以保证页面内容是可缩放的了,而且不会有夸大的现象,之后你就又可以使用em来指定其他元素的字体大小了。

默认字体大小
我们已经知道在桌面浏览器中,默认的页面字体大小是16px,所以当你把页面的font-size指定为100%时,你就能在不同的浏览器中得到相同大小的字体了。

但这一特性对于其他类型的设备来说有时就不那么奏效了。例如,当我在一台运行着黑莓6.0操作系统的黑莓手机上测试时,默认的font-size是22px,而Kindle Touch上的结果则更具戏剧性:它的初始默认大小是26px。

在你开始朝它们扔东西之前,请先听听它们这样做的原因。很多这样的新设备都有着较高的分辨率,因此16px的字体在上面看起来会非常小。大多数设备只好通过向浏览器报告说,自己有一个与实际不符的分辨率来绕过这个问题。例如,iPhone 4的分辨率为640x960,但是它会告诉浏览器自己的分辨率是320x480。

其他诸如Kindle Touch这样的设备,会向浏览器报告真实的分辨率,但会通过增大默认的font-size来进行补偿。

其实最重要的不是屏幕实际的像素大小,屏幕上文字的可读性才是真正重要的。虽然可以将基准的font-size设置为100%,但要记住用户使用的设备的基准字体大小也许不是16px(这是一个在媒介查询中使用em的好例子,我们将会在下一章讨论这方面的内容)。

2.2.4 奖励关卡:rem
还有另外一种极具潜力,并兼具灵活性的设置字体大小的方法:以rem(“root em”)作为单位。rem与em的区别在于:rem的大小与根元素——HTML元素——有关。

使用rem能够避免发生在嵌套元素中的级联问题,让我们更新一下CSS,并以rem为单位来样式化列表项:

html {
     font-size: 100%; /* equates to ~16px */
}
h1 {
     font-size: 1.5em; /* 24px / 16px */
}
span {
     font-size: 1rem; /* 16px / 16px */
}

在上面这个例子中,h1元素的字体大小依然为24px,但是span元素将会显示为16px,因为在使用root em作为单位之后,span元素将继承html元素的字体大小,而不是包含它的div元素。

但对于rem,这里有一处有关移动浏览器支持情况的告诫。通常情况下,rem在桌面电脑浏览器中都能得到很好的支持:IE9+、Firefox 3.6+、Chrome 6.0+、Safari 5.0+以及Opera 11.6+都支持rem。另外,iOS 4.0+和Android 2.1+也可以提供相应的支持。但不幸的是,在写这本书时其他移动平台(包括流行的Opera Mobile)还都不支持rem。

为了应对上面这些情况,你可以额外设置一个以像素为单位的备用方案。

span {
 font-size: 16px;
 font-size: 1rem;
}

使用上面这种方法,支持rem的浏览器将会使用rem声明,因为它是在后面声明的,而那些不支持rem的浏览器将会使用第一条使用像素的声明,并忽略rem声明。

提示
许多维护人员关心的事情其实都可以通过CSS预处理器来解决,比如SASS(http://sass-lang.com)或者 LESS(http://lesscss.org),并且可以在其中使用变量。

2.2.5 哪种单位是最具响应性的

在决定要采用哪种方式时,这里有一些权衡利弊时需要考虑的因素。使用em不但可以使文字能够缩放,而且维护起来也更加容易。例如,如果你要将整个站点的字体都增大,那么只需简单地修改body上字体的百分比即可。如果使用rem,由于需要有像素声明作为补充,所以你还要更新所有的像素值。

在本书后面的内容当中,我们将以百分比来作为body元素字体大小的单位,而以em来作为其他元素的单位。

2.2.6 从像素转换

你手中的每一个项目在刚开始时都新鲜无比,这当然很好,因为它们允许你从一开始就使用流动的设计。但事实是这样的可能性不大,因为大多数项目都会涉及迁移,此时你要能够将原有的固定大小的元素或者单位转换为一些更加灵活的东西。

鉴于此,让我们先来看一段完全以像素为单位的代码片段(图2.3)。

body {
     font-size: 16px;
     font-family: Helvetica, sans-serif;
}
h1 {
     font-size: 24px;
}
span {
     font-size: 12px;
}


2_3

在这段代码中,body的字体大小为16px,h1元素的字体大小为24px,span元素的字体大小为12px。

将上面这段代码转换为更具灵活性的代码相对来说比较容易。我们首先来设置body的字体大小:

body {
     font-size: 100%;
     font-family: Helvetica, serif; 
}

你需要记住的是,这里设置100%对于大多数浏览器来说能保证基准font-size的值为16px,此外这样做也为我们提供了一个灵活的基准,让我们能在其之上进行其他设计。

通过一个简单的数学方程式我们就能将剩下的内容轻易地转换为em了。“我知道,我知道”——如果你想做数学题,那最好还是去买本算术书吧。不过谢天谢地,你不必知道圆周率的平方根的余弦值就可以算出这里的em值了,因为方程式很简单:

目标 / 上下文环境 = 结果

以h1元素为例,对于h1元素而言,我们的目标是24px,上下文环境等于容器元素的font-size值——在这里是body的16px。所以我们用24除以16,结果是1.5em:

h1 {
     font-size: 1.5em; /* 24px / 16px */
}

注意声明后面的注释。作为一个在回顾我前一天写的代码(更不用说一个月前写的代码)时都会经常挠头的人,我强烈建议你使用注释,它们可以帮你回忆起这些数值是怎么来的。

我们可以将相同的方程式应用到span元素上。因为span元素位于h1元素内,所以上下文环境也改变了:现在是h1元素。经过计算,我们将span的font-size设置为.5em(12/24)。

更新后的代码如下所示:

1.  body {
2.       font-size: 100%;
3.       font-family: Helvetica, sans-serif;
4.  }
5.  h1 {
6.       font-size: 1.5em; /* 24px / 16px */
7.  }
8.  span{
9.       font-size: .5em; /* 12px / 24px */
10. }

灵活地指定字体大小——现在你已经实现它了!现在即使你更改了body的字体大小,body的字体大小与标题元素字体大小之间的比例也不会改变(图2.4)。


2_4


指定大小的字体完全相同,但现在当字体增大时,其比例将保持不变。

相关文章
|
16天前
|
编解码 前端开发 JavaScript
构建高效响应式Web界面:现代前端框架的比较
【4月更文挑战第9天】在移动设备和多样屏幕尺寸盛行的时代,构建能够适应不同视口的响应式Web界面变得至关重要。本文深入探讨了几种流行的前端框架——Bootstrap、Foundation和Tailwind CSS,分析它们在创建响应式设计中的优势与局限。通过对比这些框架的栅格系统、组件库和定制化能力,开发者可以更好地理解如何选择合适的工具来优化前端开发流程,并最终实现高性能、跨平台兼容的用户界面。
|
1月前
|
前端开发 开发者 UED
构建响应式Web界面:Flexbox的力量
【2月更文挑战第25天】 在现代网页设计中,创建能够适应不同屏幕尺寸的布局是至关重要的。Flexbox,一种CSS布局模式,提供了强大的工具来轻松地设计和调整灵活的响应式界面。本文将深入探讨Flexbox的核心概念,并通过实例展示如何使用它来构建美观、灵活且易于维护的响应式Web界面。
|
1天前
|
开发框架 前端开发 数据库
Python从入门到精通:3.3.2 深入学习Python库和框架:Web开发框架的探索与实践
Python从入门到精通:3.3.2 深入学习Python库和框架:Web开发框架的探索与实践
|
21天前
|
编解码 前端开发 开发者
构建响应式Web界面:Flexbox与Grid布局的深度对比
【4月更文挑战第4天】 在现代前端开发中,构建灵活且响应式的用户界面是至关重要的。随着移动设备浏览量的增加,能够适应不同屏幕尺寸和分辨率的布局技术变得必不可少。Flexbox和Grid是CSS提供的两种强大的布局机制,它们各自以独特的方式解决了响应式设计的挑战。本文将深入探讨Flexbox和Grid的核心概念、使用场景和性能考量,为开发者提供在面对不同布局需求时做出明智选择的依据。
|
1月前
|
机器学习/深度学习 前端开发 算法
利用机器学习优化Web前端性能的探索与实践
本文将介绍如何利用机器学习技术来优化Web前端性能,探讨机器学习在前端开发中的应用,以及通过实际案例展示机器学习算法对前端性能优化的效果。通过结合前端技术和机器学习,提升Web应用的用户体验和性能表现。
|
1月前
|
编解码 前端开发 开发者
构建响应式Web界面:Flexbox的力量
【2月更文挑战第28天】 在现代网页设计中,创建能在不同设备上保持一致性和功能性的响应式界面是至关重要的。Flexbox,一个CSS布局模块,为前端开发者提供了强大工具来轻松实现灵活的布局设计。本文将深入探讨Flexbox的核心概念、使用场景以及如何通过它来优化响应式设计流程。
|
1月前
|
前端开发 开发者 UED
构建响应式Web界面:Flexbox与Grid布局的深度解析
【2月更文挑战第28天】 在现代前端开发中,打造灵活且适应不同屏幕尺寸的用户界面是至关重要的。随着移动设备的普及,响应式设计已经成为网页制作不可或缺的一部分。本文将深入探讨两种强大的CSS布局模块——Flexbox和Grid,它们如何简化布局创建过程,并赋予设计师更大的灵活性去构建动态和流畅的响应式界面。通过对这两种技术的比较、使用场景分析以及代码示例,读者将能够更好地理解何时以及如何使用这些工具来提升前端项目的质量和效率。
16 0
|
1月前
|
编解码 前端开发 开发者
构建响应式Web界面:Flexbox布局的全面指南
【2月更文挑战第28天】 在当今多变的设备屏幕尺寸和分辨率中,创建一个能够适应不同视口的响应式Web界面至关重要。本文深入探讨了CSS Flexbox布局模块,它是一种设计灵活且强大的方式来创建复杂的响应式布局。我们将透过概念解析、关键属性讲解以及实际案例分析,帮助前端开发者掌握Flexbox的核心原理和应用技巧,以实现流畅的页面布局调整和优化用户体验。
|
1月前
|
监控 前端开发 JavaScript
构建高性能Web应用:前端性能优化的关键策略与实践
本文将深入探讨前端性能优化的关键策略与实践,从资源加载、渲染优化、代码压缩等多个方面提供实用的优化建议。通过对前端性能优化的深入剖析,帮助开发者全面提升Web应用的用户体验和性能表现。
|
1月前
|
前端开发 测试技术 开发者
构建响应式Web界面:Flexbox布局的力量
【2月更文挑战第24天】在现代Web开发中,创建能够适应不同屏幕尺寸的响应式界面已成为一项标准实践。Flexbox,一个CSS模块,因其灵活性和强大功能在前端开发者中广受欢迎。本文将深入探讨Flexbox的核心概念、常见用例以及如何利用它来构建美观、灵活且易于维护的响应式布局。通过实例演示,读者将学会如何有效地应用Flexbox技术,提升前端项目的质量和用户体验。