详情
随着各种各样的移动设备不断地涌现到使用者面前，对于Web设计的适应性已经成为设计师们所面临的最为艰巨的挑战。你设计出的网站不仅要在桌面计算机的大尺寸屏幕上可以为用户提供友好的UI和用户体验，同时在小尺寸屏幕上也应该可以提供一致的用户体验，并可以让用户可以在桌面大屏幕上和移动小屏幕上平滑切换，同时没有任何的不适应感觉。
本书适合从事Web设计的前端工程师和开发人员阅读参考。
侯鸿儒 译
北京
图书在版编目（CIP）数据
响应式Web设计实践/（美）卡德莱茨（Kadlec,T.）著；侯鸿儒译.--北京：人民邮电出版社，2013.3
ISBN 978-7-115-30409-4
Ⅰ.①响… Ⅱ.①卡…②侯… Ⅲ.①网页制作工具 Ⅳ.①TP393.092
中国版本图书馆CIP数据核字（2012）第304642号
版权声明
Implementing Responsive Design(ISBN: 9780321821683) Tim Kadlec
Copyright © 2013 Authorized translation from the English language edition published by New Riders.
All rights reserved.
本书中文简体字版由美国New Riders出版公司授权人民邮电出版社出版。未经出版者书面许可，对本书任何部分不得以任何方式复制或抄袭。版权所有，侵权必究。
响应式Web设计实践
◆著 ［美］Tim Kadlec
译 侯鸿儒
责任编辑 赵轩
◆人民邮电出版社出版发行 北京市崇文区夕照寺街14号
邮编 100061 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
北京捷迅佳彩印刷有限公司印刷
◆开本：880×1230 1/24
印张：11.17
字数：271千字 2013年3月第1版
印数：1-3000册 2013年3月北京第1次印刷
著作权合同登记号 图字：01-2012-5028号
ISBN 978-7-115-30409-4
定价：55.00元
读者服务热线：(010)67132692 印装质量热线：(010)67129223
反盗版热线：(010)67171154
广告经营许可证：京崇工商广字第0021号
常言道，适者生存。
人是自然界的一部分，而Web又是人造物的一部分，所以自然界的法则也理应适用于Web。今天，除了常见的手机、平板电脑和台式电脑可以上网外，小到眼镜、手表，大到电视、冰箱也都可以上网了。Web再也不是某一平台独有的矿藏，而是真正成为了一张名副其实的大网，并将各种设备彼此连接在一起。而作为这张大网中十分重要的一环——Web设计开发人员——要想不被这愈发迅猛的设备大潮所吞噬，就必须抛弃之前对Web的颐指气使，转而学会适应它、尊重它。
随着Google眼镜的推出，我们看到可穿戴计算的时代已经离我们越来越近了，这也意味着，今后会有更多我们闻所未闻的设备接踵而至。目前手机、平板电脑、桌面电脑这样的设备分化仅仅是冰山一角，更不必谈单个手机内部各种操作系统的分化了，其实最猛烈的设备多样性还在后面。倘若你不想疲于应对各种设备，或者现在的分化就已经让你筋疲力尽了，那么唯有响应式设计是最近似于银弹的子弹。
和Ajax一样，狭义上的响应式设计也并不是什么新技术，它也是一些已有技术（流动布局、媒介查询、流动媒体）的集合，只不过最先由Ethan Marcotte把它们放在了一起。但是响应式设计还有它广义的一面，即设计目标和方法的改变，也注定会对项目的整个工作流程提出新的要求。因此，学习响应式设计，除了学习那3种制胜法宝之外，还需要学习如何将响应式设计的思想贯穿到整个项目过程中去，而所有这些，本书的作者Tim都一一做了详细的介绍。
能把那么多的技术和设计理念杂糅在一起，且能做到不蔓不枝，也看得出Tim着实是一位出色的开发者。再加上大量详细的配图、注释、引用等加以说明，从中我们也能感受到这位来自威斯康星的开发者那严谨的治学态度。此外，Tim也是一位幽默大师，在翻译的过程中，我经常被他那抑或明嘲、抑或暗讽的句子逗得不行。对于这些笑料，我也在翻译过程中尽可能地保留其原汁原味。
的确，其实翻译是在犯罪。当你从原文那里感受到某种美好的东西，却不能将它如实地用母语表达时，真的会感到有所悔恨。你不是悔恨外文不通，而是悔恨母语不精。尤其是作者在每章的开头都引用了一小段文字，从漫画台词到电影台词，从伊索寓言到名人名言。不过这也让我们看到了，文化和技术并不矛盾，事实上它们是相辅相成的。
感谢人民邮电出版社的编辑在本书翻译过程中给予的帮助和指导，感谢所有参与校对工作的朋友、同学、同事。因身为学生，还略显稚嫩，虽尽力而为，但纰漏在所难免，恳请广大读者批评指正。若有任何关于本书翻译的意见，或者有关响应式设计的想法，都欢迎发送邮件至i@houhongru.com与我交流。
最后，借《海燕》里的一句话——让（设备的）暴风雨来得更猛烈些吧！
侯鸿儒
2012年10月于北京理工大学
献给我的妻子和我们漂亮的女儿们。
人们常说写书是一件孤独的事情，也许有些时候的确是这样的，但这本书却是个例外。如果这本书能得到一些好评，那么这些好评都应归功于这一路上帮助过我的那些人，以及他们的勤奋、耐心和反馈。
我要向他们致以最真诚的感谢……
Michael Nolan，最先邀请我写这本书的人，谢谢你对我如此信任。
Margaret Anderson和Gretchen Dykstra，谢谢你们能容忍我那糟糕的标点符号用法，而且还让我觉得是我通过自己的努力而摸索出了写作的要义。
感谢Danielle Foster，你让本书如此精彩，并且直到最后一刻仍然在为本书做着调整。还有Rose Weisburd、Joy Dean Lee、Aren Straiger、Mimi Heft、Rebecca Winter、Glenn Bisignani以及New Riders出版社的所有员工，感谢你们让这本书焕发出生命。
感谢Ed Merritt、Brad Frost、Guy Podjarny、Henny Swan、Luke Wroblewski、Tom Maslen还有Erik Runyon，如果没有他们乐于分享的专业知识和经验，这本书必将失色不少。谢谢他们为本书做出的卓越贡献。
感谢Jason Grigsby从头到尾一直提醒我事情还没有做完，他总能为我提供有价值的（而且经常是令人愉快的）反馈和鼓励。Jason不但是我认识的最聪明的人，而且他也是对我帮助最大的人。能成为他的朋友，对此我倍感荣幸。
感谢Aaron Gustafson写了如此精彩的前言。自从我第一次在Web上与他共事，我便从Aaron那里学到了很多——当初他同意为这本书写前言的时候，他说他是卑微的，所以让他来写序是他的荣幸——说得那么轻描淡写。
感谢Stephen Hay、Stephanie Rieger、Bryan Rieger、Brad Frost、Derek Pennycuff、Ethan Marcotte、Chris Robinson、Paul Thompson、Erik Wiedeman、Sara Wachter-Boettcher、Lyza Danger Gardner、Kristofer Layon、Zoe Gillenwater、Jeff Bruss、Bill Zoelle、James King、Michael Lehman、Mat Marquis、Nishant Kothary、Andy Clarke、Ronan Cremin、Denise Jacobs以及Cennydd Bowles的意见、反馈和鼓励。这本书在很大程度上要归功于他们之间的非凡合作。
感谢每个在这本书写作过程中通过线上或线下参与进来的人，这本书中的很多讨论都是受到了你们的启发。我们绝对是一个了不起的线上社区，能成为其中一员我深感自豪。
感谢我的父母，谢谢你们自始至终充满关爱的鼓励。
感谢我可爱的女儿们，谢谢你们提醒我片刻的休息没有什么关系，每次与你们的玩耍都让每天的生活充满了欢笑、亲吻和拥抱。
还有我无与伦比的妻子Kate。这本书，以及此外任何我做得不错的事情，都是她支持与鼓励的直接结果。对她的感谢，我无以言表。
Aaron Gustafson
几年前，传奇摄影师Chase Jarvis通过敏锐的观察发现：“最好的相机就是你手里的那部”。这句话在当时产生了不大不小的影响，但它的确一语中的：完美的拍摄很少是事先安排好的，更多的则通常发生在不经意间。
也许在你傍晚散步时光线正好打在某片红叶上；也许不知什么时候你的宝贝女儿第一次自己站了起来……类似于这样的一些时刻，无论此时你的莱卡相机搁在了另一间屋子里的书架上，还是你的Rebel相机落在了车里，这些都不重要——重要的是当时你的口袋里有一部相机，你能随时拿出它来捕捉这些转瞬即逝的场景，而无论这相机有多么普通。
Stephanie Rieger有着与Jarvis类似的观点：最好的浏览器就是你正在用的那个。毕竟，生活是不可预测的，机会稍纵即逝，灵感来得亦快且狠。
请你把自己假想成一名癌症研究员，你已经连续几个月全神贯注地做了大量的研究，希望能找出一种增加人体自身γ-干扰素的方法来抑制肿瘤的扩散。虽然你坚定的意志告诉你答案已经很近了，可你就是够不着它。直到有一天早晨，当你用热水冲去一身的疲惫的时候，灵感突然给了你一巴掌。有啦！你想你找到它了——你只需再看一遍上周看过的那篇文献。
你从浴缸里蹦了出来，站在浴室的防滑垫上，水一滴滴地落在了上面。你甚至都没有去拿毛巾，便连忙从柜子上拔掉了手机上的数据线，径直打开某个期刊网站，结果却发现自己被重定向到了一个“精简版”的网站，在那儿你只看到了一些出版物的基本资料，以及如何订阅它们的相关提示。
于是你疯狂地滑到页面底部去寻找“查看完整版本”的链接并点击，与此同时，你的手指也在屏幕上留下了一道道的水印。随着页面一点点加载，你感觉自己像是正从三万英尺的高空俯瞰主页，那大杂烩式的页面布局估计也只有不懂装懂的外行才能设计出来。
经过几分钟不停地缩小、放大、输入文字之后，你终于找到了那篇文献，但却发现它是PDF的——这几乎根本无法在手机的小屏幕上阅读。你只好垂头丧气地放下手机，失落地回到了浴缸里，只希望水流能赶紧冲走这一系列的不快。
使用手机浏览网页的结果往往都是令人沮丧的（偶尔甚至有想要咒骂的冲动），但其实本可以不像是这样。
在这本特别的书中，我的朋友Tim清晰地阐述了你能（事实上是应该）采取的步骤，从而确保你制作的网站能为每一位用户提供美妙的体验，并通过针对性能不同的设备做出相应的调整，来表达对于用户的时间、耐心和受到的种种限制的尊重。不要被Tim给你讲的“小城故事”所愚弄了，Tim知道这个领域里的一切。这本书让我受益匪浅，我想你也一定会收获颇丰的。
“只有傲慢的人，才会相信他可以规划出一座城市的每个细节；只有缺乏想象力的人，才想要这样去做。”
——John Kay
Web是一个极不稳定的环境
新的操作系统每天都在涌现，浏览器也比以往任何时候更新得都快。每天我们都会遇到形状各异的设备、浏览器功能很强的设备、浏览器功能很弱的设备、带有触摸屏的设备或者带有触控板和键盘的设备。
虽然新的设备在不断涌现，但是旧的设备和浏览器仍旧被人们所使用着。科技发展也许是日新月异的，但这也并不意味着家家户户都要跟得上最新的科技，因为今天发布的一个新设备，也许几个月之后就又被淘汰了。
很少有什么东西能够一直存留——在今天看来是正确的东西，也许明天就不再是正确的了，而所有这一切所带来的后果，无非就是混乱。
但这也正是有趣的地方——混乱造成了迷惑，但混乱也同时激发了创新和创造。新的形式因素冲击着市场，同时浏览器也在继续突破着种种限制，我们在浏览器里开发的应用程序以及使用这些应用的场景数量也在呈指数级增长。
● 形式因素
设备的尺寸、配置等其他物理特性
Web是普遍存在的，也是无处不在的。与之前的其他媒体不同，Web可以适应任何尺寸的屏幕以及任何使用环境，因为Web有其固有的灵活性和可塑性。
本章将讨论以下内容：
● 快速增长的可联网设备的多样性;
● 屏幕尺寸、网速、对于标准支持、输入方式和使用环境等因素;
● 为每一种设备创建单独的体验（背水一战的做法）;
● 响应式设计的需求，以及响应式意味着什么;
● 本书包括哪些值得你期待的内容;
● 谁应该读这本书;
● 本书的代码格式。
观察我年幼的女儿们玩耍的过程，对我来说是一段启发性的经历。每当她们得到一个新的玩具，她们总会试着用玩旧玩具的方法来玩新玩具。她们寻找着新玩具和旧玩具之间相似的特性和关系，从而能够把它们联系起来。只有当她们用这种方法熟悉了一段时间新玩具后，她们才会发现新玩具的其他新玩法。
这很有意义：过去是被我们所熟知的，而未来是未知的。我们喜欢熟悉的心理模型，我们会选择那些安全和熟悉的事物，而不是冒险和崭新的事物。但问题是，将未来建立在过去经验之上的做法，限制了新想法的萌生以及媒介的进化。
● 心理模型（亦称心智模型）人们关于现实中的事物是如何运作的思维过程。
Web 也不例外。
作为设计师，我们会尝试在Web 上重现我们对于印刷品的那种控制权。这种心态反映在我们为顾客创建网站的方法之中——我们指定特定的浏览器、我们为特定的宽度而做优化、我们用各种各样的小技巧来保证在不同平台的不同浏览器上都能创造出相同的体验。
为了拥有控制权，我们做了所有我们能做的事，但事实却是，我们从未获得过控制权：因为在Web 上，坐在电脑前的用户才是驾驶员。
用户可以选择他们喜欢的浏览器；他们可以放大或缩小字体；他们可以最大化浏览器窗口，或者只把它缩小到屏幕窗口的一半；他们可以选择使用最顶级的设备，或者选择折扣货架上三年前的老型号；他们可以在路上浏览网站，或者在家中放松时浏览——他们有权决定他们在哪里以及以何种方式来访问我们的内容。
作为设计师，我们逐渐理解了上面提到的这些内容。我们主张网站应该在任何情况下都应该看起来一样，但这样的主张表明我们还没有完全放弃争取控制权，而新设备和平台的爆炸式涌现又使得该问题愈加明显。
我是一名近乎疯狂的旅行者，我不害怕坐飞机，但我担心误机。于是我会常常发现自己坐在拥挤的候机厅里总想找点什么事做，以便用来打发时间。
于是我开始观察身边的人们，更多的时候我会去观察他们使用的是什么样的设备。在最近的一次旅途中，我飞到了一个非常小、非常偏远的机场，小到你只需要五分钟就能办完所有的登机手续。虽然候机厅里只有大概二十五个人，但是Android手机、iPhone以及一些老款的手机都能在那里见到。有人在用Nook读着什么，而我旁边一位头发花白的老太太正在用她的iPad看着新闻。
我们上了飞机。在空姐示意可以重新使用电子设备之后，人们便纷纷把手伸进了各自的包里。之前的那位老太太坐在我前面两排靠近过道的位置上，只见她取了手提包，从中拿出一部Kindle并开始阅读。当我们快要降落的时候，她把Kindle放了回去，继而又拿出了一部iPhone。
这位老太太在大概五个小时的时间里，使用了三种不同的设备来进行阅读。对于近年来非PC设备的大量涌现，无疑这是一个小小的缩影。
截至2011年年底，全世界大约有59亿手机用户——占世界总人口的87%，而且这一数字有望继续稳定增长：全球智能手机的出货量在2010年第四季度第一次超过了PC。
移动设备上的Web浏览量也在逐年上升，其中部分原因是现在的手机提供的浏览体验已得到大幅提升。在早期，可以访问互联网的手机还只是少数人的时尚用品，那时手机的硬件能力非常有限：只能识别XML的简化版本的无线标记语言（Wireless Markup Language，WML）、网络慢到令人无法忍受、屏幕也很小、输入法用起来更是让人显得尴尬而笨拙。
尽管随着科技的进步移动设备在不断地进化，一些具有很强功能的设备从2000年早期就开始出现，但是直到2007年iPhone的首次发布，才使得整个行业的游戏规则得以改变。霎时间，你便可以在你的移动设备上感受“完整的Web”了。iPhone以及后面接踵而来的各种智能手机的浏览体验，一扫之前人们对移动设备浏览功能的所有不满。
为人们提供一种不那么糟糕的使用体验会产生一个有趣的现象——人们会更频繁地使用。2011年，在线音乐网站Pandora的移动流量占其总流量的60%，而这一数字在2009年的时候还只有25%。同一时期，社交网站Twitter的移动流量也从25%上升到55%（图1.1）。实际上，手机网站的流量在2010年猛增了600%。
也许手机是一类不容忽视的设备，但绝不是造成这场混乱的唯一一种设备。由苹果的iPad所领军的平板电脑，在手机和笔记本电脑之间架起了一座桥梁——平板电脑一方面提供了手机的便携性，同时又不失近似于笔记本电脑的大屏幕。据估计，到2015年，平板电脑的销售额将达490亿美元。
虽然带上网功能的电视机市场目前还是一个相对年轻的市场，但是随着谷歌和苹果这样的重量级选手的加入，想必在不久的将来这块市场会非常有潜力。与此同时，微软的Xbox 360和任天堂的Wii等内置浏览器的游戏设备，也使得用户可以通过电视屏幕来浏览Web页面。
被亚马逊的Kindle系列产品和巴诺的Nook占据大片市场的电子书中同样内置有浏览器。虽然也许比起平板电脑、智能手机或者PC的浏览器来说，电子书的浏览体验不是那么细致而优雅，但你可别被它们愚弄了、觉得人们不会使用它们。在这个网络连接无处不在的时代，最好的浏览器就是你手里的那个。
由此可见，现如今的网站比以往任何时候都更需要能够在不同的设备上被使用，而每一种设备又都是种种限制与功能的组合。
虽然设备的屏幕尺寸一直都在变化，但是至少我们可以预测出它们的发展趋势。1984年发布的第一款Macintosh的分辨率是512×342，随着时间的推移电脑屏幕的分辨率也在稳步提升——在十年之后的1994年，苹果发布了分辨率为1024×768的17英寸显示器。
事物的发展瞬息万变，随后可联网的移动设备开始登场。自从2007年iPhone为我们带来了320×480的分辨率后，我们已经无法想象以后的分辨率还会有怎样的提升。
仔细观察一下周围你就会发现，受人们欢迎的设备的屏幕宽度从280像素到1920像素不等。地毯已然从我们的脚下被抽走——再也没有标准的分辨率可寻。
网速对于用户的Web使用体验有着巨大的影响，但不幸的是，网速总是戏剧性地不断变化着——前一个访问者也许是通过高速带宽的有线连接访问网站的；后一个访问者也许是通过低速率高延迟的EDGE移动网络访问网站的。
● 延迟
数据从一点发送到另外一点的等待时间。
有些设备或运营商允许用户利用他们的手机创建移动热点，这样用户的笔记本电脑就也可以接入移动网络了，而同时智能手机也能像笔记本那样接入Wi-Fi网络，因此设备与网络之间的相关性正在减弱，虽然我们可以对此做一些猜想，但这些猜想已远不及之前那么准确了。
我们应该感谢各种平台、浏览器和设备数量的增长，因为这使得竞争空前激烈，同时也促使各浏览器相继实现对于新标准的支持，而且其实现速度也是空前的。
但是，革命性增长的脚步在带来稳定的同时，也带来了同样多的混乱。“支持”这个词被人们用得太过宽松了——它已经不再是一个布尔值，而是成为了一种程度。虽然很多浏览器都声称支持同样的特性，但其语法还是会略有区别：有一些浏览器只支持一部分标准；而另一些更糟糕的浏览器打算将标准和他们自己的属性做一个混合式的实现，最后创建出了一团乱麻似的语法。
最糟糕的是许多尖端设备上的浏览器对于标准的支持也很有限。例如在大城市里非常流行的Kindle，作为人们阅读的主流设备，Kindle也有一个内置的浏览器，但是由于它只能使用和电子书一样的电子墨水来显示内容，因此所有内容都只能是灰阶的。
虽然没有人们说的那么糟糕，但IE 6和Kindle自带的浏览器对标准的支持确实有待提高，但这也并不表明没人会使用它们。当人们被诱惑说可以像对待二等公民那样来对待这些对标准支持欠佳的浏览器时，其实这种观点是无法令人接受的，因为被归到这个等级里的某些设备是全新的而且也是高质量的。
长久以来，人类与计算机之间都有着相对稳定的交互方式。键盘始于打字机，鼠标始于苹果1984年推出的Macintosh（事实上，鼠标的原型可以追溯到20世纪50年代，但那时它还未引起人们的注意，直到后来被整合到Macintosh中）。
很多时候，事物发展的规律看起来都是往复循环的，但手机的发展还是给人们带来了一丝震颤。几乎一夜之间，手机输入方式囊括了滚动球、触控板，以及那些小到可怕的、难以按到的按钮（或只是因为我的指头太过肥大了？）。
之后触摸屏上的各种手势又成了人们需要面对的更为复杂的操作，因为人们需要给予触摸设备特别的考虑：按钮的大小要适于人们手指点击。不像那些非触摸的操作，这里可没有鼠标悬浮状态可供使用。虽然触屏设备会照顾到JavaScript的鼠标事件，但与触摸屏固有的触摸事件相比，单击等事件会有人们能明显察觉得到的延迟。此外，触屏设备还有很多固有的交互方式，例如滑动、下拉刷新以及拖动等等，所有这些触屏设备独有的操作方式，都需要有与之相对应的处理脚本和样式。
设备在物理上和架构上的特性，并不是我们在针对设备进行设计时需要考虑的唯一因素，人们会在什么样的环境下使用设备是另外一个大大的问号。
人们可能在各种环境下使用各种设备：在家里、在路上、在公交车站、在白天、在夜晚、在被朋友或者陌生人围绕时，而且这些使用环境也无法与设备的类型相关联：虽然外出时会经常使用手机，但在家里沙发上休息时也会使用；虽然笔记本会经常被放在桌子上使用，但坐火车时也可以拿出来用。
虽然使用环境是一个讨论不完的话题，但我们也不能忽略掉它。我们将在第9章“响应式体验”的讨论中回到使用环境的问题上来。而现在，你只要认识到——了解使用环境是从响应设备的Web到响应人的Web的关键，这就足够了。
我前面曾经提到设备的多样性导致了混乱，但通常我们人类是一个喜欢稳定的物种，所以对于人们应对多样性想到的第一个办法是为不同设备创建独立的用户体验，我想，对此你应该不会感到太意外吧。
在写这本书的时候，也许最普通的处理设备多样性问题的方法，就是为特定种类的设备（或者在被极端误导的情况下，为每一种特定的设备）开发一个独立的站点，通常这种做法会开发一个移动设备站点和一个台式电脑站点（如图1.2所示）。然而如果采用这种方法的话，站点无疑会变得越来越多：对于一个公司来说，需要有一个台式电脑站点、一个平板电脑站点、一个可触摸移动设备站点以及一个类似的却不支持触摸的移动设备站点。一个公司拥有四个不同的站点，这似乎有点不太合常理。
这种方法当然有其优点：为每一种设备创建独立的站点，使得站点从内容到行为上都更容易为提高使用体验而进行有效的裁剪。但这是否有效，还要取决于具体的项目——商业目的、用户、团队能力、预算以及所有其他有趣的商业因素都在共同起着作用。
但可惜的是，这种方法无法很好地进行扩展：四个站点需要分别进行更新、测试以及维护。通常而言，即使只创建一个站点就需要好几名工程师了——想象一下，当项目需要创建四个站点时，每个工程师肩膀上的负担有多重！更有甚者甚至建议还要为每个站点定制内容，这无疑又要求人们投入更多的时间和精力。
分歧
有时人们会问我是否想到过收敛的问题，即是否可以通过减少设备和平台的种类来解决上面这些复杂的问题，对于这些人，我只想对他们说一个词：僵尸。
作为Web上最好的文章之一，在“The Coming Zombie Apocalypse”（即将到来的僵尸启示录）一文中，作者Scott Jenson认为：设备的多样性将会加剧。他断言不仅科技会继续加剧多样性，成本的降低也会起到同样的作用：
“智能手机硬件的商品化仅仅是个开始，集成了‘片上系统’的设备以及免费克隆版Android Linux系统的价格暴跌，不但使设备的价格更加低廉，而且使基于云计算的设备的价格也进一步走低。这些设备已经被用在了索尼爱立信的LiveView，以及类似于Sonos家庭音乐系统这样的家庭应用当中。
这些例子还都仅仅是个开始，有迹象表明，新一轮数量巨大的廉价设备即将入侵我们的生活——电子僵尸启示录，如果你愿意这样叫的话。”
市场看起来好像的确是在迎合Scott Jenson的理论——智能手机变得越来越便宜，哪怕是那些长期以来一直算是比较昂贵的手机（比如某些版本的iPhone），现在也已经可以在签订合约之后免费获得了。
随着这些设备制造成本的下降，该领域的准入门槛也会随之降低，并向越来越多拥有更多系统和设备的厂家敞开了大门。事实上我们不会看到任何收敛：新设备会如洪水般涌现，而且它们会成为影响Web体验的因素。
即使今天我们可以跟得上独立站点的脚步，那么明天我们该怎么办？虽然这是个比较极端的例子，但是如果有一天冰箱也可以上网，难道那时的我们也要尝试去为冰箱创建独立的站点吗？
如果何物体都可以被当做屏幕会发生什么？2011年，微软发布了一款被称为OmniTouch的原型设备，它是一个可以放在你肩膀上的、沉重而丑陋的设备。无疑它在美学上是欠缺的，但它却在别的方面补偿了我们无数个惊讶——它可以将显示的内容投影到任何物体上——墙上、地板上、甚至是你的手上，如图1.3所示，你还可以与投影交互。OmniTouch去掉了所有显示器固有的限制，从而使得任何物体都可以是屏幕。我倒是很好奇，什么时候我能见到为人类手掌优化过的网站。
开发独立站点并不是一种未来友好型的方法，为了能在即将到来的海量设备大潮中生存下来，我们必须拥抱Web的灵活性。
2010年5月，Ethan Marcotte为“A List Apart”写了一篇题为“Responsive Web Design”（响应式网页设计）的文章，他在文章中描述的方法不仅简单，同时又是革命性的。Ethan Marcotte利用三种已有工具：媒介查询（media queries）、流动布局（fluid grids）和自适应图片（scalable images）创建了一个在不同分辨率屏幕下都能漂亮地显示的站点（图1.4）。
在文章中，Ethan Marcotte力劝设计师们要去利用那些Web独有的特性：
“我们可以将不同联网设备上众多的体验，当做是同一网站体验的不同侧面来对待，而不要为每种设备进行单独裁剪而使得设计彼此断开，这才是我们前进的方向。虽然我们已经能够设计出最佳的视觉体验，但还要把基于标准的技术也嵌入到我们的设计中去，这样才能使得我们的设计不仅灵活，而且还能适应渲染它们的各种媒介。”
这篇文章受到了人们极大的赞扬，而且也理应如此。Marcotte证明了一种在多种设备上都能提供卓越体验的方法的存在，而且这一方法不会忽视不同设备的差异，也不会强调设计师的控制权，而是选择了顺其自然并拥抱Web的灵活性。
在这里，我需要首先澄清一个问题——响应式站点不等于移动站点，这一点已经导致了人们颇多的迷惑和激烈的辩论。当然，响应式设计的很大一部分魅力就在于它也可以作为移动站点的开发策略，但这仅仅恰好是一种快速建立移动站点的方法罢了，并不能说明什么。
响应式站点不是移动站点、不是台式机站点，也不是平板电脑站点。Marcotte在他的博客文章“Toffee-Nosed”（趾高气昂）中明确地指出了这一点：
“每当我谈论或者撰写有关响应式设计的东西的时候，我总是希望强调非常重要的一点：响应式设计不是‘为移动设备而设计’，它也不是‘为台式机而设计’，它是关于采用灵活的、设备无关的方法来为Web进行的设计。”
● 设备无关
所有的东西（组件、布局等）都能与不同类型的设备和平台相兼容。
设备无关的概念非常重要，因为我们不知道用户会用什么样的设备来访问Web，没有什么媒体会在如此宽泛的设备、被如此多的用户所访问。所以，作为设计师，我们应该把所有情况都囊括进来。
虽然我们还远远没有弄清所有的东西，但是托已有大量工作和实验的福，响应式设计方法较它的第一个版本已经有了大幅的提升。虽然那三个元素（媒介查询、流动布局和自适应图片）仍然是它的核心内容，但它们也只是冰山一角。
后来人们发现，一个成功的响应式的设计方法其实是建立在与渐进增强非常相似的原则之上的。其实，响应式设计就是打了激素的渐进增强。
关于未来友好型
你会在这本书中看到很多次“未来友好型”这个词，其实它指的是“未来友好宣言”。
“未来友好宣言”是由一些高标准的Web设计原则所组成的集合，并最初由一些移动开发者创立。虽然随着时间的推移，具体的技术会淡入淡出，但它们留下的价值却将得以保留。当你决定要采用什么技术来实现你的项目时，请记得下面这些原则。
以下为宣言摘录，摘自http://futurefriend.ly：
激光般专注
我们不可能在所有设备上实现所有的事情。为了能在一个设备激增的世界里掌控复杂局面，我们需要专注于那些对客户和业务来说，最最重要的事。
以数据为中心
作为一个由设备所组成的生态系统，就要求系统内的设备之间能够彼此协作，而具有鲁棒性的数据交换是实现这种协作的最简单的方法。要积极应对现有的和新出现的机遇，并以下面介绍的这些方式来定义数据：多样（灵活）的访问和通知途径、通过标准来协作、侧重于长期的完整性、包含有意义的且永久的内容引用、支持读写操作。
通用内容
结构良好的内容现在已经成为了网站里必需的一部分。考虑到这些内容将会流入到形形色色的容器中去，我们就要留意这些容器的限制和功能。我们在大胆探索新的可能性的同时，也要清楚未来的发展方向。
识别未知的船
针对所有的设备差异作出相应设计是极具挑战性的任务，一个高级且足够准确的设备种类数据库能够帮我们简化适应这些差异的过程。
领导你的舰队
在生活中拥有广泛的设备，可以让我们将任务和信息分发到它们上去。当我们通过设备集合来管理单独设备上的体验时，单个设备便可以以自己最擅长的方式来处理交互了。这样便免无需为每种设备单独裁剪服务，同时还能让我们在一个由设备所组成的生态系统中工作。
渐进增强
很长一段时间以来，Web社区一直都在提倡“优雅降级”——一个从类似于计算机网络这样的计算机领域中借用过来的词。其主要思想是：当你利用所有新的特性（那些能力最强的浏览器支持的特性）时，你要保证那些相对较老的浏览器也能访问你的内容。
这听起来或许没有什么不妥之处，但却从中发展出了一种不负责的心态，即对于那些较老的浏览器上的体验，人们便不会尽力去做，而是认为随便什么样都可以。只要以某种形式提供了内容即可——不管体验会有多么的糟糕——你仍然成功地运用了优雅降级。
优雅降级不见得是未来友好型的，它表现出了一种对使用旧浏览器的用户的不尊重，而且忽视了现实状况，因为还有很多崭新的设备（手机）也只带有能力较弱的浏览器。
在2003年的SXSW活动上，Steven Champeon和Nick Finck进行了一场介绍“渐进增强”（Steven提出的新概念）的演讲。
渐进增强从本质上来说，就是把优雅降级给倒了过来。不像优雅降级那样先为最新的、最强劲的浏览器开发站点，然后再让功能较差的浏览器能使用多少就使用多少功能；相反，渐进增强会先创建一个基本体验，该基本体验使用具有语义的标记和结构定义，并侧重于让内容以一种简洁的方式来展现，同时这也是一种具有可用性的形式。
之后，在保证基本体验的前提下，才开始着手做有关显示的布局和交互，但此时会为能力更强的浏览器创建更丰富的体验。
一直提倡这一方法的Aaron Gustafson将渐进增强比作是一颗花生M&M豆：内容是花生，样式部分（CSS）是巧克力，交互部分（JavaScript）是糖衣。虽然内容可以单独存在，但当你在最外面加了功能层之后，体验就变得更加丰富而完整了（图1.5）。
响应式设计使用了同样的思想，并会针对不同的设备提供适当的内容和布局。即先从一个基本的体验开始，然后使用流动布局和媒介查询这些技术来为功能更多、屏幕更大（功能更多和屏幕更大并不总是同义的）的设备增强使用体验。
其实现在我们在实施响应式设计方面还没有取得什么成就，因为响应式设计要求我们对我们之前处理Web的方式进行重新翻修。由于能够迎接我们想到的挑战的工具和流程都还没有出现，所以我们需要先后退几步并问自己一些问题：
● 把台式电脑的体验设为默认体验是否有意义？
● 我们该如何调整工作流程，来应对不同设备和不同尺寸屏幕上的设计和原型？
● 我们该如何以一种更加结构化的方式来存储内容？
● 内容管理系统和所见即所得编辑器是否有天生的缺陷？
● 我们是否应该重新考虑一下长期以来令人厌恶的用户代理（UA）字符串？
● 用户代理字符串
由用户代理传递的、用来识别浏览器以及操作系统等其他信息的字符串。
● 如何让内容变得更加便携？
● 如何应对未来爆炸式增长的设备？
● 现有标准（HTML、CSS）是否有能力支撑起如此多样化的Web？
● 我们如何在接纳不同使用环境的前提下，又不失彼此体验的一致性？
其中一些问题很容易回答，但回答另外一些就比较困难了，还有一些问题则仍在讨论之中。Marcotte除了在2010年5月写了那篇介绍新技术的文章外，他还做了更多的事情：他发起了一场更大范围的讨论，包括我们的行业所必需的成熟性。
这就是这本书要讨论的——拥抱Web的灵活性并实践响应式设计。接下来的几章将会从头到尾引导你学习你将会用到的技术，这些技术将能增强站点，而且无论使用什么设备来访问，这些技术都能够创造出令人愉快的用户体验。是的，答案总会有，但问题也总会有，这就是比其他任何媒体发展得都要快的Web的本性。
本书由9章内容组成，包括你现在正在阅读的介绍章节。接下来的3章内容介绍了响应式设计的3个原则。
● 流动布局
这章讨论如何抛弃固定布局设计，并开始建立流动布局以及流动排版。
● 媒介查询
这章介绍了媒介查询：媒介查询的类型、如何使用它们以及如何确定断点。
● 响应式多媒体
这章关注图片和视频等具有固定宽度的元素，并会讨论该如何把它们合并到响应式布局中去。
在牢固地树立了上述3条原则之后，本书剩下的部分将会对响应式设计是如何影响现有的Web设计过程的进行探究。
● 计划
这章讨论成功地规划一个响应式站点需要哪些必备的步骤。
● 设计工作流程
这章会考察响应式设计是如何影响设计过程的。具体来说就是会关注响应式设计的步骤和交付物，以及我们需要为此作出的一些改变。
● 响应式内容
这章讨论如何规划、创建以及在响应式布局中展示内容。
● RESS
这章包括如何将响应式设计和检测方法相结合，例如客户端特性检测和服务器端用户代理检测，并提出更加健壮的解决方案。
● 响应式体验
最后一章关注如何将响应式的心态应用到整个Web体验中去。具体来说就是如何利用环境和独特的设备性能，来创造出一种真正迎合用户需求的体验。
这本书本意上是为那些希望能在无尽的设备上创建出具有良好界面和功能的站点的设计师和开发者而写的。你不需要有任何响应式设计的经验——前面的几章会让你跟得上的。
但你应该精通HTML和CSS，同时至少要熟悉JavaScript。第8章“RESS”中会涉及一些PHP的代码，但即使你没有太多的PHP知识，你应该也能很容易地接受文中提到的概念。
本书从头到尾包含了各种各样的代码示例，类似于下面这样：
1.<html>
2.<head>
3. <title>Geolocation</title>
4. <meta name="viewport" content="width=device-width" />
5.</head>
6.<body>
7. <p>Testing the geolocation API.</p>
8. <div id="results"></div>
9.</body>
被修改过的代码部分会高亮显示，从而让你能更容易地找到它们。
在有些例子中，为了节省空间，没有更改过的代码会被省略，并用3个点来代替，如下面第7行代码所示：
1.<html>
2.<head>
3. <title>Geolocation</title>
4. <meta name="viewport" content="width=device-width" />
5.</head>
6.<body>
7. ...
8.</body>
关于本书中的JavaScript
现在平均每个网页的大小竟然有1MB，而这1MB中有大约200KB是JavaScript代码，这一数据相比去年增长了52.6%，这真是一个非常糟糕的趋势。
尽管不是全部，但大部分JavaScript的膨胀，都可以归因于业界对于库和插件越来越多的依赖。拿到那些提前打包好的解决方案的确是件诱人的事，因为很多时候它们都已经过测试并配备有文档，但它们并不总是必需的。根据你要解决的问题，你常常可以“侥幸地”只使用其中的一小部分代码。
本书中所有的JavaScript都没有使用任何流行的库。我想澄清的一点是，我不反对使用库，事实上你将在本书中见到几个很有用的jQuery插件。我想说的其实是：你一定要仔细考虑要将什么东西包含到你的页面中来。如果你需要某个库，那就去用它；如果你不需要，那么不如自己写一段代码来节省一些页面大小。
一棵大橡树被风连根拔起，然后落到了一片芦苇丛中。橡树对芦苇们说：“我很想知道，你们如此轻而弱小，却为什么没有被大风吹走呢？”芦苇们回答道：“你和大风打斗对抗，结果就被摧毁了；而我们在大风来临之前便弯下了腰，并因此保持完好而存活了下来。”
——“橡树与芦苇”伊索寓言
在“橡树与芦苇”的故事中，大橡树和芦苇都被风吹来吹去，橡树想要一直站得又高又稳，并因此与大风做着顽强的抵抗，但最终它还是被大风给打败了。
与之相反，芦苇则弯下了腰，当然也不是它们想要这样，只是它们能弯得下腰。它们不与大风对着干，而是就让自己随风摇曳。虽然被大风吹得扭曲甚至彼此缠绕在一起，但毕竟它们最后还是活了下来。
长期以来，我们其实都是在按照橡树的思维方式来建立网站的，主要表现为设计中的一些硬性规定以及使用固定宽度。它们看起来好像很不错，直到它们不可避免地遇到了我们无法预知的Web。现在的我们需要去拥抱Web，而不是与无法预知的Web也来场对抗。
这也是John Allsopp在2000年为A List Apart写的“A Dao of Web Design”（Web设计之道）中所极力指出的。在这个今天还是最佳实践，而明天就有可能成为笑柄的业界，Allsopp的见解后来被证明是难得的先见之明——他认为Web社区需要拥抱Web的灵活性，同时不要再将Web的不可控性视为是一种限制：
“我相信，Web最伟大的优点常常被人们视为是限制和缺陷。灵活性是Web固有的本性，作为设计师和开发者的我们，应该去拥抱它的这一特性，并且要设计开发出同样具有灵活性的页面，使得所有的设备都可以访问。”
Allsopp认识到Web的灵活性和不可预测性不应该是我们与之斗争的对象，因为这些都是Web的特性，而不是它的漏洞。也正是由于这些特性才使得Web如此独特，以至于成为了比印刷品还要强大的媒介。
随着越来越多设备的涌现，人们越来越难以继续忽略Web所固有的灵活性和不可预测性。终于在12年之后，业界才终于赶上了Allsopp那篇文章中提出的新思潮。而作为拥抱灵活性的第一步，就是要为我们的站点创建流动布局，并藉此来对不同尺寸的设备屏幕作出不同的响应。
在本章中你将会学到：
● 四种不同的布局类型；
● 指定字体大小的几种不同方法，以及如何从中作出选择；
● 如何创建流动布局；
● 如何将固定宽度的资源（比如图片）与流动布局很好地结合起来；
● 如何利用display:table来结合使用固定宽度和流动宽度。
要想弄清楚在哪些情况下灵活布局可能会是我们最好的选择，我们就要先知道我们还有哪些选择。只有先明白了每种选择的优缺点，我们才有可能做出正确的决定，并保证我们的站点能在各种环境中发挥出最大优势。
在广受好评的《Flexible Web Design（灵活的Web设计）》一书中，作者Zoe Mickley定义了4种布局类型：固定布局、流体布局、弹性布局和混合布局。
这里提到的每种布局都有着它们各自的优势、劣势以及面临的挑战。
在固定布局中，页面宽度会被指定为特定大小的像素，其中960px是使用最为广泛的宽度。Cameron Moll在2006年发表的一篇名为“Optimal width for1024px resolution？”（1024px分辨率屏幕的最佳页面宽度？）的文章中，对越来越流行的1024分辨率屏幕的“最佳”页面宽度进行了仔细的分析：在考虑了Chrome之后，他认为最佳页面宽度应该介于974px到984px之间。但相比其他数值而言， 960对网格布局则更加友好（因为960可以被3、4、5、6、8、10、12和15整除，所以可以为网格布局提供多种可能），而且它也能与互动广告局（IAB）（译者注：互动广告局是一个非盈利性的广告商业组织，主要负责研究、制定广告标准，并为在线广告业提供合法支持）的标准广告大小很好地配合，因此这一宽度得到了广泛采用。
固定布局是Web布局中最为常见的实现方式，因为固定布局会给人一种对页面拥有较多控制权的错觉。能确切地知道你的站点会以多宽来显示，这使得你能创建出拥有大量图形的设计，而且即使在不同的屏幕上，它们也能看起来相当一致。
然而，固定布局最大的问题在于，你做的一切都是在许多假设前提之下的。当你决定站点应该有多宽时，你不得不去猜测什么样的尺寸可以照顾到大多数的访客，而这其中又暗藏着比从表面上看起来多得多的技巧。早在智能手机、平板电脑这些设备出现之前，就已经存在了大量使用不同大小屏幕的访客了，而这也仅仅是个开始，因为有些人并不会全屏浏览网页，还有些人的浏览器装有带边栏的插件——这些都在很大程度上降低了站点可以利用的实际空间。
此外，固定布局带给我们的所谓“一致性”的优点其实也带有些许误导。如果你的站点是960px宽的，当访客使用屏幕较小（假设是800px宽）的设备浏览站点时，他将只能看到站点的一部分，而且还会看到一个丑陋的水平滚动条（图2.1）。
大屏幕设备也同样存在问题：如果有人用大屏幕设备浏览960px宽的站点，那他就会在页面两边看到大片的、未使用的空白区域。虽然留白作为设计的一部分固然是好的，但是对于人们意料之外的大片空白，我想没有谁能从中获益。
严格的固定布局在今天广泛而多样的设备生态系统中早已问题重重，因为当今很多最新、功能最强的手机和平板电脑的浏览器都会默认显示缩小之后的网页，以此来适应它们那较小的屏幕。虽然可以在屏幕上通过手指来缩放页面（当然提供这样的放大功能总比不提供要好），但这样的操作还是会让人感到繁琐，况且这一过程也远远不能称之为是一种享受。
注意
Gillenwater在她的分类中称为流体布局；在本书中称为流动布局。
在流动布局中，度量的单位不再是像素，而是变成了百分比，这样可使页面具有可变的特性。你可以设计一个占容器宽度60%的内容栏、一个占容器宽度30%的边栏，以及一个占容器宽度10%的分隔区域。采用这种方法定义，意味着你不用再去关心用户使用的到底是1024px宽的桌面浏览器，还是768px宽的平板电脑浏览器，因为元素的宽度会根据浏览器窗口的宽度自动进行调整。
流动布局的设计可以避免许多会在固定布局中遇到的问题，例如，在大多数情况下，流动布局中都不会出现水平滚动条。由于站点可以根据浏览器窗口的宽度来自动调节自身宽度，因此站点将可以充分利用并适应各种大小的可用空间，从而也就避免了在使用大屏幕设备浏览固定布局时，人们所不愿见到的大片空白出现。
同时，在实施诸如媒介查询、针对不同分辨率优化样式这样的响应式策略时，流动布局能使这些策略更容易实现（我们会在后面的章节中对此做详细的介绍）。由于没有那么多的问题需要修复，所以需要写的CSS也相对较少。但是，单独使用流动布局这一种方法依然不足以保证所有元素在从手机到电视机等一系列设备都能保持良好的效果。因为有些文本的行宽在大屏幕上看起来会太宽，而在小屏幕上又看起来太窄。流动布局仅仅是个开始，后面还会有为什么这本书没有到此为止的其他原因。
弹性布局与流动布局类似，只是它们的度量单位不同——通常情况下，在弹性布局中会以em来作为单位。1em相当于当前字体的大小，例如，如果body的字体大小是16px，那么此时1em就等于16px，同理2em等于32px。
弹性布局为设计师们在排版方面提供了强大的控制权。大量研究表明，理想的阅读文本的行宽介于45到70个字符之间。利用弹性布局，你可以将容器的宽度设定为55em，这样就可以使容器维持在一个合适的宽度了。
弹性布局带来的另外一个好处是随着用户增大或者减小字体，使用弹性布局的元素的宽度也会等比例地变化，我们会在后面讨论字体大小时进一步讨论这个问题。
但是，在弹性布局中也可能出现令人讨厌的水平滚动条。如果你把字体大小设置为16px，并把容器宽度设置为55em，那么就会在任何宽度小于880px（16×55）的屏幕中出现水平滚动条。弹性布局中的这个问题甚至比固定布局中的情况还要有更多的不确定性，因为如果用户把字体放大到了18px，那么你的容器宽度便会达到990px（18×55）。
我们的最后一个选择就是混合布局，它结合了上面提到的两种或两种以上的布局方式。
例如，假设你有一个300px宽的广告区域，那么你可以将放置广告的边栏指定为固定的300px宽，其余各列的宽度则以百分比为单位。这样做即保证了广告的宽度是固定的300px（考虑到第三方的广告服务，这样安排是很有必要的），同时除边栏之外的其他内容也能填满剩下的整个空间。
● 视口
浏览器呈现网页时的可见区域。
但是在流动布局中使用上面这种方法会很容易使页面变得凌乱不堪，如果把边栏设置为300px宽，把主要内容栏设置为70%，那么当屏幕宽度小于1000px时，你还是会遇到水平滚动条的问题。因为此时300px宽的边栏已经超过了分配给它的宽度，即视口宽度的30%，剩下的空间已经小于了内容栏所要求的70%。不过万幸的是，还有另外一种创建混合布局的方法，我们会在后面的章节中提到。
如果你是毫无压力地读完上面这一段的，而且没有回想起你高中的数学课，那么我可就要为你鼓掌了。
那么到底哪种方式才是正确的、能对于各种设备和环境都具有响应性的呢？从根本上来说，这取决于你特定的项目，因为每一种方法都有其优势和不足。
大多数情况下，最佳答案是更具灵活性的那几种布局——流动布局、弹性布局或者混合布局——因为相比固定布局，它们对未来更加友好。
虽然能够通过使用媒介查询来在几个固定布局之间来回切换，但这样做仍旧存在限制。因为使用一个这样的“可切换”的固定布局，会使得你的站点在某几个特定分辨率的屏幕中显示得非常好，但在这几个值之间过渡的那些分辨率的屏幕中就会显得比较尴尬。这样一来，用户就会受到你的决定的支配：如果他的设备与你选定的不一致，那么他的体验还不如你什么都不做时好呢。
● 媒介查询
媒介查询允许你根据设备的信息——诸如屏幕宽度、方向或者分辨率等属性来使用不同的样式。
所以，虽然“可切换”的固定布局的方法在大方向上是对的，但这有点像是每天晨跑前，你都要花30分钟先坐在沙发上吃个冰激凌一样——虽然有总比没有强，但你没有得到你本应该得到的全部。
相反，如果你使用流动布局，至少你已经得到了很大一部分。甚至没有媒介查询的帮助，你的设计都能够在不同的视口之间作出调整，虽然会有一些不完美。
当你开始强调媒介查询的作用时，你便很容易忽视掉另外一点：其实是弹性布局或流动布局在发挥更主要的作用（参见第3章）。流动布局为你做的事情越多，你需要创建的断点、写的CSS代码就越少。当你有了一个强大的流动布局的时候，媒介查询就会弱化为一种调整设计的手段，而不必再去重新创建另外的设计。
● 断点
那些被指定的、开始应用某一新的媒介查询的点。例如，一个在980px处的断点的意思是，当浏览器宽度大于或小于这一数值时，新的媒介查询将被触发。
要想让你的设计拥抱Web的流动性，那就意味着在你的设计中要能够灵活地改变字体大小。你可以在Web上使用任意单位来设置字体大小，但主要的方法不外乎三种：像素、em，还有百分比。
长期以来，像素一直都是人们喜欢使用的字体大小单位，其原因很简单：无论浏览器如何设置字体大小，你都能对其进行精确的控制。如果你把字体设置为18px，那么每个浏览器都会将其准确地显示为18px。
但这样的掌控是要付出一定代价的。对于初学者而言，虽然使用像素作为字体大小单位时不需要考虑级联——父元素的字体大小对子元素没有影响，但这也意味着当你想让某些文本以不同的大小显示时就需要对它们逐一设置。这对于维护来说非常不利，因为当你想增大所有字体时，你就不得不去逐一修改每一个值。
更重要的是，以像素为单位的字体存在着潜在的可访问性问题。所有主流的浏览器都允许用户放大或缩小页面，浏览器对该操作通常有两种实现方式。
第一种方式是简单地将页面上所有的东西都放大，所以当访问者放大页面时，包括文本在内的所有的元素都会变大。在这种情况下，无论字体大小使用哪种单位，都允许用户进行缩放（图2.2）。
另外一种方式是浏览器只调整文本的大小，页面上其他元素则保持不变。长期以来这都是常见的浏览器实现方式，并且现在仍有一些浏览器采用这种方式实现缩放功能。
而且不幸的是，以像素为单位的字体在老版本的IE中是无法实现缩放的。这意味着那些使用IE9之前的、字体被设为默认大小的IE浏览器（或者在最新版中启用了字体默认大小的浏览器）的用户，是不能调节你的页面中字体的大小的。
无法调整字体大小的问题也同样出现在很多较老的、在触摸屏出现之前就已经存在的设备上。有时所有的页面内容都不能缩放，在这种情况下，虽然字体还是同样的大小，但部分页面也许就不太适合人们阅读了。
浏览器能够调整文本的能力给了用户更多的控制权，另外作为浏览器本来就应该实现的功能，这样做也可以提高站点的可访问性。因为对于某些访问者来说，当字体大小小于某一数值时，就会给他们的阅读造成障碍。所以允许用户增大字体就意味着他们可以继续享用你的站点里的内容。
用像素指定字体大小依然不是一种对未来特别友好的方式。由于不同的设备有着不同的屏幕大小和像素密度，因此以像素为单位的字体也许在这台设备上看起来不错，但在另外一台设备上看起来也许就会要么太大、要么太小了（本章后面“默认字体大小”对此会做进一步的讨论）。使用像素作为字体大小的单位，是与Web的灵活性原则背道而驰的做法。
使用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选择器，用来匹配特定元素的子元素。
和以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的好例子，我们将会在下一章讨论这方面的内容）。
还有另外一种极具潜力，并兼具灵活性的设置字体大小的方法：以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），并且可以在其中使用变量。
在决定要采用哪种方式时，这里有一些权衡利弊时需要考虑的因素。使用em不但可以使文字能够缩放，而且维护起来也更加容易。例如，如果你要将整个站点的字体都增大，那么只需简单地修改body上字体的百分比即可。如果使用rem，由于需要有像素声明作为补充，所以你还要更新所有的像素值。
在本书后面的内容当中，我们将以百分比来作为body元素字体大小的单位，而以em来作为其他元素的单位。
你手中的每一个项目在刚开始时都新鲜无比，这当然很好，因为它们允许你从一开始就使用流动的设计。但事实是这样的可能性不大，因为大多数项目都会涉及迁移，此时你要能够将原有的固定大小的元素或者单位转换为一些更加灵活的东西。
鉴于此，让我们先来看一段完全以像素为单位的代码片段（图2.3）。
body {
font-size: 16px;
font-family: Helvetica, sans-serif;
}
h1 {
font-size: 24px;
}
span {
font-size: 12px;
}
在这段代码中，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）。
◆提示
可以访问http://implementing responsivedesign.com/ex/ch2/ch2.1.html来查看实际效果。
注意
关于网格的更多信息，可以参阅Khoi Vi n h的书籍，或者找一份Mark Boulton的系列视频来看。
早在Web出现前的数十年，在设计中使用网格就已经是一种异常流行的做法了，因为网格有助于实现站点的平衡、间距以及组织结构。一个实现良好的网格系统会使你的站点井井有条，同时还可以提高页面的可读性和可浏览性。
在《“Ordering Disorder: Grid Principles for Web Design”（秩序之美：网页中的网格设计）》一书中，作者Khoi Vinh便强调了使用网格进行设计的四大主要优势。当你把这些优势同时运用在设计中时，你会看到它们之间更为紧密的联系。
● 网格使信息的展示变得有序、新颖、和谐。
● 网格使得用户能够预测该从哪里获得信息，这在信息交流过程中很有帮助。
● 在与原始总体设想相一致的前提下，网格使添加新的内容更为容易。
● 网格能在设计单一解决方案时促进合作，而不必对总体设想的解决方案妥协。
框架简述
在网上可以找到大量基于网格的框架，这些框架模板和CSS规则能帮你快速搭建出预先定义好的网格布局。在这些框架中，有些是灵活的，而有些则不是，它们中的大多数都介于12列至16列之间。虽然在每个新项目中都使用你最喜爱的框架是一件诱人的事，但其实我们可以做得比这更有创意。
虽然使用12列的网格并没有什么不妥，但是如果在每个站点中都使用12列的网格就会产生让人感到厌烦、可预测的布局。为了能够从网格布局那里获得最大的益处，你得针对每个项目重新考虑一下框架。
大胆地去合并那些列，并实现一个3列或者5列的网格吧！那些设计得最为漂亮的Web站点，没有一个会使用被人们用烂了的12列布局的——有时越简单越好。
使用网格布局要做的第一件事就是确定画布。在图形设计中，画布就是你的纸，它的大小决定了网格。你得先把画布划分为若干你需要的列（3列、5列、9列，甚至12列），然后才能继续后面的工作。
正如我们之前讨论过的，在Web上没有像在纸上那样准确的尺寸，你得工作在内容之外，并让内容来决定网格。
为了清楚起见，这里需要说明的一点是，当我说“内容”的时候，我并不是特指文本，我说的内容有很多种形式：广告、视频、图片、文本。这些不同类型的内容都可以决定你的网格。例如，如果你的公司是一家出版公司，并且收入主要来自于广告，那么比较明智的做法是围绕IAB的一两个特定的广告大小来确定你的网格。同样，如果你正在重新设计一个有很多遗留图片的大型网站，那么你就要根据这些图片来确定你的网格。
让你的内容来决定你站点的结构是一种很好的设计方法，而且这样做也是非常实用的。相比把遗留的图片或者广告硬塞进一个事先就定义好的网格中，不如从一开始就让你的网格来配合它们，这会让每个页面的设计都更具粘性。
已经唠叨得够多了，下面让我们来动手写一些代码吧。
◆提示
可以访问http://implementing responsivedesign.com/ex/ch2/ ch2-start.html来查看实际效果。
让我们从一个虚构的体育刊物——《另一个体育网站》（原创的，这我知道）开始吧。我们将为文章页面设计一个网格，默认的颜色和字体样式已经写好了（出于示例的考虑，我们要等到下一章才会引入页面的header和footer）。让我们先来看一下需要处理的内容：
1. <body id="top">
2. <div id="container">
3. <article class="main" role="main">
4. <h1>That guy has the ball</h1>
5. <p class="summary">In what has to be considered a development of the utmost importance, that man over there now has the ball.</p>
6. <p class="articleInfo">By Ricky Boucher |<time>January 1, 2012</time></p>
7. <section>
8. <img src="images/football.jpg" alt="Football" />
9. <p>...</p>
10. </section>
11. </article>
12. <aside>
13. <section class="related">
14. <h2>Related Headlines</h2>
15. <ul>
16. <li>
17. <a href="#">That Guy Knocked Out the Other Guy</a>
18. </li>
19. ...
20. </ul>
21. </section>
22. <section class="ad">
23. <img src="images/ad.png" alt="Boombox ad unit" />
24. </section>
25. <section class="article-tags">
26. <h2>Tagged</h2>
27. <ul class="tags">
28. <li><a href="#">Football</a></li>
29. ...
30. </ul>
31. </section>
32. <section class="soundbites">
33. <h2>Sound Bites</h2>
34. <blockquote>
35. ..this much is clear to me.If I were in his shoes, I would have already won 5 Super Bowls.
36. <cite><a href="#">—Guy with big ego</a></cite>
37. </blockquote>
38. </section>
39. </aside>
40. <div class="more-stories">
41. <h2>More in Football</h2>
42. <ul class="slats">
43. <li class="group">
44. <a href="#">
45. <img src="images/ball.jpg"alt="Look, it's a ball!" />
46. <h3>Kicker connects on record 13 field goals</h3>
47. </a>
48. </li>
49. ...
50. </ul>
51. </div>
52. </div><!-- /#container -->
53.</body>
我们是水平最高的开发者，所以对于要在页面上显示什么内容我们早已成竹在胸，而且还为我们的设计创建了牢固的HTML结构。在我们的页面中会包括一篇文章，每篇文章又会包括一个用h1元素表示的大标题、作者名字以及一则概述，之后便是放在section元素内的文章正文部分了。
每个文章页面还会有一个边栏，里面包含一个最近文章标题的无序列表。由于《另一个体育网站》如果不通过广告来收费的话，那么它还需要去寻找别的赚钱途径，因此每个文章页面还需要有一个300px × 250px的广告空间。这是我们遇到的第一个限制，我们可以根据该限制来设计网格。
◆提示
可以在https://github.com/robbiemanson/960px-Grid-Templates查看Robbie Manson在Github上的代码仓库，里面有可以在Photoshop和Fireworks中使用的各式各样的模板。
最后，边栏中还需要有一个与文章相关的标签列表，并引用一些他人的言论。其中标签以无序列表的形式展示，而引用则要放在blockquote元素当中。
让我们先来用一种古老而传统的方法来创建我们的网格——以像素为单位。
960px，让我们尝试使用9列网格来取代经常使用的12列网格。9列网格的每一列都为84px宽，而且它们之间还有24px的间隔，共计948px。一个300px宽的广告可以很容易地放到网格的最后3列当中去，剩下的6列则留给文章内容使用。
首先，我们来设置容器元素的宽度：
#container{
width: 948px;
}
然后让文章和边栏分别向左、右浮动，并为它们指定适当的宽度：
aside {
float: right;
width: 300px;
}
.main {
float: left;
width: 624px;
}
到此为止，布局看起来已经相当可爱了。网格让设计中的元素看起来是有联系的，而且文章的宽度也非常利于阅读，这会使用户的阅读过程非常轻松。
但是，当你缩小浏览器窗口时，问题便会马上暴露：当浏览器宽度小于948px的时候，我们又看到了讨厌的水平滚动条，屏幕中又不能同时显示所有的内容了（图2.5）。
◆提示
可以访问http:// imp-lementing responsivedesign.com/ex/ch2/ ch2.2.html来查看实际效果。
虽然我们已经设计出了一个不错的网格，但它目前还只适用于一小部分用户使用，下面让我们来做一些弥补吧，好吗？
让网格变得灵活
如果此时你想起了前面让字体变灵活的方法，那么其实你可以把同样的方程式（目标/上下文=结果）应用在灵活化网格布局上来。
容器的上下文是948px，在这样的容器里实现流动布局是件很容易的事：
aside {
float: right;
width: 31.6455696%; /* 300/948 */
}
.main {
float: left;
width: 65.8227848%; /* 624/948 */
}
Box-sizing
如果你看过上面这个页面的样式表，那么也许你会注意到下面这3行代码几乎应用到了所有元素上：
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
CSS中默认的盒模型会让人觉得有问题：你本来已经定义好了width，但你之后定义的所有padding又都会被算到这个width中去。例如，如果你创建了一个300px宽的列，之后在其左右各加了20px宽的padding，那么此时该列的宽度就会变成340px。这在人们创建基于网格的流动布局时，会使人感到相当痛苦。
通过使用box-sizing: border-box，你就可以让浏览器将padding的值算在已经定义好的元素宽度内部了。通过使用这一属性，一个300px宽的列即使两边新增了20px的padding，它的宽度依然会是300px，因为padding的宽度被算在了元素内部。这使得设计流动布局变得更加容易。
在不使用box-sizing的情况下（如右图所示），一个宽为300px且有20px padding的元素，其宽和高都会变为340px 。而在使用了box-sizing后，元素仍然是300px宽、300px高。
在包含了box-sizing的各种版本的前缀之后，这一属性就可以获得很好的浏览器支持了。在桌面及移动设备的主流浏览器中，只有IE8之前的IE浏览器对此缺乏支持。实际上，大多数浏览器对此已经支持了很长一段时间了，比如Chrome和Firefox，从第一个版本开始就支持前缀语法了。
最后，我们来让页面中的其他部分也流动起来。
.main {
float: left;
margin-right: 2.5316456%; /* 24px / 948px */
width: 31.6455696%; /* 300/948 */
}
现在，内容栏和边栏都实现了流动布局，下面我们要将容器上现有的固定宽度也去掉。我们将页面容器的总宽度设置为95%来取代之前的948px，留一点padding（译者注：指剩下的那5%）能给页面一些呼吸的空间：
注意
为什么是95%？其实没有什么确切的原因。我试了几种不同的宽度，结果95%在不同的浏览器宽度下都显示得非常好。有时候，设计中真的就是靠看和感觉来定的。
#container{
width: 95%;
padding: .625em 1.0548523% 1.5em; /* 10px/16px, 10px/948, 24px/16px */
margin: auto 0;
}
在这个例子中，我们使用em作为顶部和底部padding的单位，并使用百分比作为左右两边padding的单位，之所以要这样做是由上下文所决定的。因为顶部和底部的padding值是由font-size的大小决定的，所以使用em更有意义。
流动世界中的固定宽度对象
下一个要讨论的对象就是图片。当你缩放浏览器窗口时，有着固定宽度的图片就会变得极为醒目，因为与周围其他流动的内容相比，它们会显得格格不入。在较宽的列中它们只会占据一小部分；而在较窄的列中它们又太宽。不过谢天谢地，让它们变整齐也是很容易的。
我们要做的第一件事，就是使用下面的声明来让图片填满整个边栏：
aside img,
.main img,
.slats img {
width: 100%;
}
这里需要注意的很重要的一点是，不能在HTML中设定img元素的height和width的属性值，因为如果设定了这些值，就不能按比例缩放图片了。为了使流动图片正常工作，你只能通过CSS来控制图片的大小。
然后我们需要声明max-width。通过将max-width设置为100%，我们便可以告诉浏览器不要让图片的大小超过了它的容器元素（本例中是边栏）。这样，即使浏览器窗口变窄，图片也不会溢出或被裁剪了：
aside img,
.main img,
.slats img {
width: 100%;
max-width: 100%;
}
至此，我们便拥有了一个流动布局——能够自适应地调整自己，而且在大部分的设备上都是可用的（图2.6）。在提升有关图片的体验方面我们还有很多事可以做，我们将在第4章中再对此做详细介绍。
◆提示
可以访问http://implementing responsivedesign.com/ex/ch2/ ch2.3.html 来查看实际效果。
到目前为止，文章页面看起来已经很不错了，而且布局十分灵活，下面让我们来加强一下右侧的边栏。现在它看起来好像没什么问题，但是如果我们能让它保持300px宽，而只让主体列流动岂不是更好？虽然这不是必需的，但是考虑到边栏里的广告，我想这将会是一次很好的润色。
使用浮动来实现这个任务几乎是不可能的。正如我们之前讨论过的那样，主要内容栏的宽度依赖于屏幕的分辨率，如果我将边栏设置为固定的300px宽，同时保持主要内容栏为当前的63.125%，那么我们将遇到前面在浏览器宽度小于960px时遇到的同样的问题。
有一种方法可以绕过这个问题，其中会涉及CSS表格。
表格布局——正确的方法
不久以前，在一个离我们不太遥远的星球，那里多数的Web站点都是使用表格来布局的。那是一种缺乏语义的、散乱到让人看了想哭的实现方法，但它的确是有效的。后来那里出现了一场Web标准化运动，并提出了要将内容和表现相分离的理念，突出强调了使用语义标记的重要性。一场伟大的战役便随之而来，并最终以标准的获胜而告终。
相比CSS布局，表格布局的优势之一在于它简化了将站点布局为多列的实现过程。可以混合使用固定宽度和流动宽度；一行里可以包括好几列——所有这些在表格布局中实现起来都相当容易，而用CSS来实现这些样式则远没有那么简单。
其实你可以给display属性赋予许多不同的、与表格相关的值，并以此来实现上述的那些样式，因为display的一些属性值可以让元素获得与表格相关元素相似的布局效果。
如果在CSS中使用表格值的做法会让你觉得不爽，那么我想你不该因此而受到指责。毕竟，基于表格（table）的布局曾一度受到了人们猛烈的抨击，你也许非常理解那种甚至看到厨房里的桌子（table）都会感到恶心的感受。但是，在CSS中使用表格值与使用HTML表格来布局还是有很大区别的，CSS中的表格值只是给内容定义了视觉样式，而并不是说表格也是内容的一部分。
到目前为止，display属性的表格值还没有得到广泛的使用。对此你也许可以指责IE，因为Firefox、Safari以及Opera都已经支持表格值有一段时间了，而IE直到IE 8才开始支持表格值。在写这本书时，IE 6和IE 7总共的市场份额已经下降到了5%以下，所以我想现在是时候扫扫CSS表格值身上的尘土，并开始使用它们了，更何况移动平台对此的支持也相当棒。
如果将某列的display属性指定为table-cell，我们就可以混合分别使用固定宽度和流动宽度的列了：
.main {
display:table-cell;
}
aside {
display:table-cell;
width: 300px;
}
这时当我们再来缩放浏览器，边栏将仍旧保持300px，而左边的主要内容栏则会进行调整以填满剩余区域。虽然现在两列之间没有了漂亮的间隔，但我们可以很容易地通过增加一些padding来让它重现：
.main {
display:table-cell;
padding-right: 2.5316456%; /* 24px / 948px */
}
现在，我们已经能够将固定宽度的列和流动宽度的列结合在一起使用了，这使得我们在保证布局灵活性的同时，不必再去担心在混合布局中引入浮动时会造成的混乱了（图2.7）。但主要内容栏在高分辨率的屏幕中显示时还是会有一些不妥之处（译者注：因为在高分辨率屏幕下主要内容栏会变得很宽，过宽的行不利于人们阅读），我们将在下一章探索媒介查询时再去解决这个问题。
对老版本IE的支持
对于很多站点来说，也许本章到此就可以结束了，因为IE 8之前的各种版本的IE正在迅速失去各自的市场份额。其实这仍然是由你的用户来决定的，让那些旧版本的IE以它们现有的方式来呈现网站也许是不够的。虽然可以显示网站的内容，但你的客户也许并不满足于这样的设计，这时你就要准备一些备用的样式了。
条件注释可以帮你达到上面的目标，因为条件注释能让特定版本的IE浏览器使用另外的样式表。例如，我们创建一个叫做ie.css的样式表，并且规定只在IE 7及以下版本的IE中才加载它，那我们就可以使用下面这样的条件注释：
<!--[if lt IE 8]>
<link rel="stylesheet" href="/css/ie.css" media="all">
<![endif]-->
现在，任何IE 8之前版本的IE就都会加载ie.css了。这样，我们便实现了为较早版本的IE浏览器提供备选样式表的目标。
Display:table的告诫以及未来
在你变得兴奋并开始在所有项目中都使用display:table之前，这里有一些你需要意识到的潜在问题。
第一个问题是：在一个被指定为display:table-cell的元素内，你无法精确地定位元素。如果你需要精确地定位，你就不得不在表格中插入另外一个div，或者干脆就不要使用display:table。
另一个需要牢记的一点是：相对来说，表格是更加严格的。有时浮动所具有的流动性是有利的，比如如果有些内容过长的话，那么浮动可以很容易地让超出的部分折回到下面去。
Web设计中没有银弹（译者注：银弹是指那些可以解决复杂而棘手的问题的方法或者技术手段），你会看到我在后面还会提到这句话的。所以你必须在提交任何方案之前，仔细考虑你的需求，包括使用display:table。
CSS网格布局和Flexbox是两种新的布局方法，它们可以为我们提供更多种类的控制，而且值得我们关注。但现在浏览器对它们的支持还都非常有限，这也是我们使用display:table的原因。
现在唯一的问题是Windows Phone 7也会加载这个备用样式，鉴于此，我们将在下一章中利用媒介查询来针对小屏幕修改样式表，因为我们不想在手机中让备用的样式表覆盖现有的样式。幸好我们只需在条件注释中做一处小小的修改，就可以修复这个问题了（该方法最先由Jeremy Keith提出）：
<!--[if (lt IE 8) & (!IEMobile)]>
<link rel="stylesheet" href="/css/ie.css" media="all">
<![endif]-->
既然我们可以在不影响手机体验的前提下提供备选样式，那么我们就先将ie.css文件中的样式变回两列浮动的流动布局：
.main {
float: left;
width: 65.8227848%; /* 624/948 */
}
aside {
float: right;
width: 31.6455696%; /* 300/948 */
}
虽然在老版本IE中达不到那些对标准支持更好的浏览器中显示时的效果，但这已经足够了。记住，站点不需要在不同设备的不同浏览器中看起来都一模一样，事实上这也是无法做到的。即便是现在这样，那些老版本IE的用户也照样可以看到一个对于他们的浏览器来说合适且良好的布局。
◆提示
可以访问http://implementing responsivedesign.com/ex/ch2/ ch2.4.html 来查看实际效果。
大多数情况下，流动布局（以百分比为单位，因而可以根据屏幕大小来调整自身的布局）是你设计站点时的最佳选择。当宽度被字体大小限制时，你可以使用弹性布局；当宽度被百分比限制时，你可以使用流动布局。
采用更加灵活的方式来指定文字大小可以使维护工作变得更加容易，同时这样做也提升了站点的可访问性。为了达到这个目标，我们就要坚持使用百分比和em，尽管rem在未来很有潜力。
通过定义网格，有助于为你的网站提供良好的结构并增加一致性。要试着从内容出发来建立你的网格，而不是随意拿一个事先就定义好的网格来用。这就意味着我们要根据行宽、图片、广告大小或者其他标准来建立网格。
将固定单位转换为灵活的单位与计算一道除法题一样简单，因为在指定元素宽度以和字体大小时，你用的都是那个方程式。
通过使用CSS表格，你可以很容易地将固定宽度与流动宽度结合使用，现代的桌面浏览器对此特性都有着极为出色的支持，而且你还可以通过使用条件注释来为IE 7及以下版本的IE浏览器提供备用样式。
现在，“另一个体育网站”的文章页面的布局已经变得灵活了许多，而且相比采用固定布局也能够适应更多种类的分辨率了。然而它现在还不是真正响应式的，因为当浏览器变得很窄的时候，我们依然会遇到很多样式上的问题，而且如果屏幕太宽的话，我们的设计也不是特别整洁。
在下一章中，我们将使用媒介查询来解决上面这些问题。媒介查询使我们可以根据用户使用的设备来改变页面的样式，这一强大的技术将带领我们走向真正的响应式设计。
