Responsive Web Design
响应式Web设计
ETHAN MARCOTTE原作 于2010年5月25日
http://alistapart.com/article/responsive-web-design
设计师熟知的在印刷媒体的控制功能，常常也会期望Web媒体会有，但是他们仅仅限制在打印出来的页面上才能使用。我们必须接受这样的事实：web根本没有同样的限制和为这样的弹性准备的设计。但是首先我们必须接受这种落差和流程。
——John Allsopp, “A Dao of Web Design”
英国建筑师Christopher Wren有一次开玩笑说他选择了一个"以永恒为目标"的领域，而这样的原则也有它吸引人的一面：不像是Web那种总让人感觉是以下星期为目标的东西，建筑是一个以他的持久性来定义的学科。一个建筑的地基决定了它的底座，底座决定了他的结构，结构决定了它的外观。建筑的每一个阶段都比上一个阶段更固定，更难以改变。创造性的决定极其确切地决定了物理空间的形状，规划好了人们几十甚至几百年间在这个范围中活动的方式。
然而在Web上工作则是完全不同的事情。我们的工作内容由瞬时性定义，经常在一两年里就要调整或者替换。不一致的窗口宽度，屏幕分辨率，用户偏好以及我们用户安装的字体仅仅是在交付工作时要衡量的奇怪东西中的冰山一角。经年累月我们逐渐变得不可思议地精于此道。
但是形势在变化，而且可能比我们想要的还快。移动浏览量预计三到五年内会超过桌面访问。在三个具有支配地位的视频游戏平台中就有两个有Web浏览器（而且其中一个还非常棒。）。我们为了鼠标和键盘设计，为T9键盘设计，为手柄游戏控制器设计，也为触屏设计。简而言之，我们现在要面对比以往任何时候更大数量的设备、输入方式以及浏览器种类。
近年来，我见到更多公司开始要求"iPhone版网站"作为他们项目的一部分。这是一个很有趣的说法：从表面来看，当然，这是说移动版WebKit完全达到浏览器的品质，同时也是跳出桌面思考的一个强有力的商业案例。但是作为设计师，我觉得我们经常从这样明确的要求中寻找安慰，因为他们允许我们把面前的问题划分开来。我们可以把移动体验明确地隔离到单独的子域和空间中，跟"非iPhone版网站"分开。但是接下来呢？一个iPad网站？再来一个N90网站？我们真的能一直这样保证为每一种新的用户代理提供专门为之设计的体验？从某种意义上讲，这开始感觉像是一个零和游戏，但是我们——以及我们的设计——该如何适配呢？
弹性的基础
让我们考虑一个设计的例子。我创建了一个简单的幻想杂志页面。它是在流体格上的直接的两栏布局，其中到处散布着一些弹性的图片。作为非固定布局的长期支持者，我长期认为它们更加"面向未来"仅仅因为它们不针对特定布局。在某种程度上，规则是：弹性设计没有对浏览器窗口宽度做任何假设，并且非常漂亮地适配了具有人像和景物图模式的设备。
但是不论是固定设计还是流体设计，没有任何设计可以在超出它最初考虑的环境时缩放自如，示例中的设计在浏览器窗口大小改变时完美地缩放，但在更低分辨率下关键点很快出现了，当用比800x600更小的视口去观看时，logo后面的插图被截断了，导航文本则在不合适的地方换行，图片和按钮因为过于拥挤而失去易读性。而不仅仅是分辨率过小时的造成的影响：当用宽屏去看这一设计时，图片立刻变成了笨拙的尺寸，挤开了周围的内容。
总的来说，我们的弹性设计桌面环境工作良好，因为它原本就是为之设计的，但是不能够搞定差得太多的情况。
支持响应
最近，一个新兴的学科名为"响应式结构设计"（译者注：这是建筑学领域的概念）开始设问物理空间到底能用于让多少人通过它们。通过嵌入式机器人技术和伸缩性材料，建筑师试验使得艺术装潢和墙体结构在收到挤压时能够弯曲、弹性和扩展。在装满人的时候，运动传感器与气候控制器配合以控制温度和周围光线。一些公司已经生产出了"智能玻璃技术",能够在屋子里的居住人数量达到一定阈值的时候自动变得不透明，以给予他们一层额外的隐私保护。
在他们的书"响应式结构设计"中，Michael Fox 和 Miles Kemp描述这个更接近于"一个可以对话的多重循环系统；一个持续而有创造性的数据交换中心。"强调下我的看法，在我看来这是一个微妙但是强有力的区别：比起之前所说的固定的、不变的空间来规定特定的体验，他们揭示了居住者和建筑物之间可以，也应该动态地互相影响。
这就是我们要前进的道路。与其为每一种数目不断增加的web设备裁切出一种毫无关联的设计，我们可以将他们视为同一种体验的不同面。我们可以为最佳视觉体验来设计，但是在我们的设计中加入基于标准的技术是的它们不仅仅是弹性的，而且更好地适配到渲染它们的媒体上去。简单地说，我们需要实践响应式web设计。但是怎么做呢？
初识media query
在CSS2.1时代，我们的样式表可以通过媒体类型来判断设备。如果你有写过打印用的样式表，你应该非常熟悉这一概念：
<link rel="stylesheet" type="text/css" href="core.css"
media="screen" />
<link rel="stylesheet" type="text/css" href="print.css"
media="print" />
因为想要让我们设计出来打印格式更好的页面，CSS标准提供给我们一系列的可接受媒体类型，每一种都为特定的已知可以访问web的设备定制。但是多数浏览器和设备从来没有拥抱这一标准的精神，留下了大量实现不完整的媒体类型，或者根本就给忽略掉。
谢天谢地,W3C搞出来了media query作为CSS3标准的一部分，改进了媒体类型的承诺。media query允许我们不仅仅以特定设备类型为目标，还可以真正地检查设备用来渲染我们作品的具体物理特征。例如，随着移动WebKit的崛起，media query成为受欢迎的客户端技术，可以为iPhone、Android手机和他们的亲戚提供裁切讲究的样式表。要想做到这个，我们可以把一个查询条件写入外链样式表的media属性：
<link rel="stylesheet" type="text/css"
media="screen and (max-device-width: 480px)"
href="shetland.css" />
这个查询条件包含两部分：
- 一个媒体类型(screen), 以及
- 由圆括号括起来的真正查询条件，包括要检查的特定媒体特征(max-device-width)后跟目标值(480px)。
用通俗地话说，我们要求设备的水平分辨率(max-device-width)等于或者小于480px。如果这个检测通过——也就是说，如果我们的作品在小屏幕设备如iPhone上面，设备就会加载sheland.css。否则，外链就会被完全忽略。
设计师们过去就曾经实践过针对分辨率的布局，大部分都依赖像是Cameron Adams的nb脚本一样的JS驱动的解决方案。但是media quey标准提供了一个媒体特性的宿主，它远不止屏幕分辨率那么简单，它极大地扩展了我们可以用查询来检测的范围。还有就是，你可以在一次查询中同时检测多个属性的值，只要使用and关键字链接起来就可以了：
<link rel="stylesheet" type="text/css"
media="screen and (max-device-width: 480px) and (resolution: 163dpi)"
href="shetland.css" />
还有更多，我们不仅仅可以在link标签中引入media query。我们也可以把它们直接包含在CSS中作为@media规则的一部分。
@media screen and (max-device-width: 480px) {
.column {
float: none;
}
}
或者作为@import指令的一部分。
@import url("shetland.css") screen and (max-device-width: 480px);
然而在每一种情况下，作用是一样的：如果设备通过了我们设置的media query检测，相关的CSS就会作用到我们的标签，简单来说media query对于其它人来说就是条件注释。并非针对特定版本的特定浏览器，我们可以以外科手术手法去纠正我们布局在缩放到并非原始和完美尺寸时出现的问题。
适配、响应与克服
现在我们转过来看看页面底部的图片。在他们默认的布局中，有关的CSS看起来像是这样：
.figure {
float: left;
margin: 0 3.317535545023696682% 1.5em 0; /* 21px / 633px */
width: 31.121642969984202211%; /* 197px / 633px */
}li#f-mycroft,
li#f-winter {
margin-right: 0;
}
我漏掉了几个排版属性而专注于布局：每个 .figure元素尺寸为包含它们那一列的大约三分之一，每一行的最后的图片（li#f-mycroft, li#f-winter）右侧的margin被清零。这个可以很好地解决问题，然而这可视区域一旦显著地小于或者宽于我们原本的设计就不行了。用media query，我们根据特定分辨率做定点修复，适配我们的设计以应对显示。
首先，在可视区域的分辨率降低到最低限600px的时候，让我们来把页面变成单栏。这样在样式表最底部，我们创建一个新的@media区块，像是这样：
@media screen and (max-width: 600px) {
.mast,
.intro,
.main,
.footer {
float: none;
width: auto;
}
}
如果你在一个现代桌面浏览器看我们更新后的页面，然后把窗口尺寸减小到600px以下，media query将会关闭设计中主要元素的浮动，在文档流中顺次堆叠这些区块。这样我们的小型化设计就很好地做出来了，但是图片还没有很智能地缩小。如果我们引入另一个media query，我们可以相应地改变它们的布局：
@media screen and (max-width: 400px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 48.341232227488151658%; /* 306px / 633px */
} li#f-watson,
li#f-moriarty {
margin-right: 0;
}
}
不要在意这个很丑的百分比；我们只是重新计算了流体格的宽度来适应新的单栏布局。简单地说，当可视区域的宽度下降到400px以下的时候，我们从三列的布局切换到二列的布局，让这个图片看上去更突出。
我们也可以给宽屏的显示切实地做一些事情。针对高一些的分辨率，我们可以把图片适配到六栏布局，把它们全都放在同一行：
@media screen and (min-width: 1300px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 13.902053712480252764%; /* 88px / 633px */
}
}
现在我们的图片在分辨率谱系中的两段都可以完美展现，可以根据窗口和设备分辨率自动优化它们的布局方式。
但是这只是个开始。通过我们嵌入在CSS中的media query，我们能改变的不仅仅是几张新图片的摆放：我们可以引入新的，可以更改的布局以搭配各种分辨率区段，可能使得导航在大屏幕视图下更加突出，或者在小屏幕中重新定位到Logo上方。
而响应式设计并不仅仅是布局改变。media query允许我们实践中改变自己的形态做到令人难以置信地高精确性适配页面：我们可以在小屏幕上增加目标区域或者链接，在触屏设备上更好地遵循费茨法则（译注：Fitts's law）；有选择地展现或者隐藏用于改善页面导航元素。我们甚至可以实行响应式排版来更改文本的尺寸和框线，为提供显示的设备优化阅读体验。
一些技术摘记
值得一提的是，media query的健壮性在现代浏览器中令人难以置信。桌面浏览器如Safari 3+, Chrome, Firefox 3.5+, 和Opera 7+ 都原生地支持media query, 更近一些的移动浏览器如Opera Mobile和移动WebKit也是如此. 当然了，这些桌面浏览器的旧版本不支持media query。而虽然微软承诺在IE9中支持media query，但是Internet Explorer现在没有原生实现（译注：此文写的时候IE9还没出来，IE9和IE10确实已经完整支持了media query）。
尽管如此，假如你对于在遗老遗少级别的浏览器上实现media query，这里有JavaScript带来的一线曙光：
- 有一个2007年的jQuery插件提供了不完全的media query，仅仅在加到不同的Link元素时提供了支持min-width和max-width两个媒体属性的支持.
- 更近一点的事情，css3-mediaqueries.js已经发布，这是一个承诺要在使用@media块包含的时候“使得IE 5+, Firefox 1+ 以及Safari 2 对使用者透明地解析、检测和应用CSS3 Media Query”的库。在1.0版本发布的时候，我个人发现他很健壮，我计划要关注它的开发进程。
但是如果使用JavaScript无法引起你的兴趣，这也是完全可以理解的。然而，这可以加强在弹性格的基础上做布局的案例，确保你的设计在没有media query的浏览器和设备上也利用了一些弹性设施。
前路展望
流体网格，弹性图片以及media query是响应式web设计的三个技术要素，同时他要求一种新的思维方式。除了把我们的内容分成完全不同的、设备相关的体验之外，我们可以使用media query来对我们的工作在不同的视觉上下文中做渐进增强。这不是说没有适合将网站分成特定设备的商业案例；比如，如果用户到你的移动站点来的想要找的东西比桌面内容更少，那么提供不同的内容就是最合适的做法。
但是这样的设计思想不应该是我们的默认选项。现在比起以往任何时候，我们的设计工作都更倾向于不同梯度的体验中展现。响应式web设计给我们提供了一个前进的道路，最终让我们能够做到"为事物的涨落而设计"。