灵活性：响应式设计的基石
4.68/5 (4投票s)
灵活性：响应式设计的基石
如果你在过去一年左右没有与世隔绝，你应该知道，响应式网页设计是当今最热门的趋势之一。由Ethan Marcotte提出，这个概念很简单：通过使用能够适应和响应不同设备和分辨率的方法来开发网站。
当我第一次听说这个概念时，我立刻被吸引住了——尤其是在使用媒体查询这一点上，我立即将其应用到了我自己的自由职业网站上。我甚至写了一篇关于这个过程的文章：《使用CSS3媒体查询响应不同设备》。(我强烈建议你在深入阅读本文之前先阅读那篇文章。请继续。我等你。)
由于我第一次尝试媒体查询的经历，我很快意识到我缺少了响应式设计方程式中的一个关键部分：灵活性。
固定宽度的挑战
我的自由职业网站是一个固定宽度的设计，这意味着所有的宽度、边距和内边距设置都以像素为单位指定。传统上，这是我在构建网站时的偏好，因为对我来说它更简单、更快捷。
但当我为我的固定宽度网站编写媒体查询时，那些更简单、更快捷的方面迅速消失了。为什么？因为对于固定宽度的设计，我发现我需要非常详细和冗长的媒体查询来调整CSS中每一个像素值。我基本上是在为每一种可能的屏幕分辨率创建一个全新的布局。不简单。不快捷。不有趣。
然后我有幸在In Control 2011大会上听了Marcotte先生的演讲。他讨论了响应式设计作为一种理论，然后深入探讨了实用性，比如流式网格。
流式和灵活的公式
流式布局是灵活的。它们会随着浏览器窗口大小的改变而改变，因为宽度、边距和内边距元素（甚至是字体和图片）都使用百分比和em等比例值来指定。随着分辨率的变化，布局会成比例地调整。而且这一切都不需要一个媒体查询。
这就是我获得响应式设计“啊哈”时刻的时候。如果我的布局是基于比例值，那么流式网格将承担我所需的大部分繁重工作。我的媒体查询就不需要包含样式来本质上覆盖我所有的宽度、边距和内边距值了。
与此同时，我也有了一个“哎呀”的时刻。流式网格需要计算来确定那些比例值。而我数学很差。
幸运的是，Ethan提供了一个实现流式网格的公式，它看起来足够简单（即使对我来说也很简单）。
target ÷ context = result
这个公式取页面上一个元素（目标）的基于像素的宽度，除以其父元素（上下文）的基于像素的宽度。结果将成为目标元素的比例宽度。
例如，在图 1中，其中一个深灰色容器的宽度是300像素，它包含在960像素的浅灰色容器中。在这里，960像素的容器是上下文，300像素的容器是目标。那么我们的数学公式就是
300 ÷ 960 = 0.3125
结果 0.3125 需要转换为浏览器能理解的值，所以将其转换为百分比。这只需将小数点向右移动两位，得到31.25%。然后，在CSS中，将该百分比指定为元素的宽度。
1. aside {
2. background-color: #ccc;
3. float: left;
4. width: 31.25%;
5. }
付诸实践
尽管这个公式看起来很简单，但我知道我必须将其应用于一个真实的网站才能确定。幸运的是，我最近加入了EE Podcast，我们正在重新设计网站。当我的联合主持人递给我她的Photoshop样稿时，我承诺要以灵活的布局开发这个网站。
比例宽度
我首先记录了所有元素宽度的值。（我们在样稿设计中没有严格遵循网格，但我会推荐）。正如你在图 2中看到的，头部的主要容器宽度为940像素，而logo、主持人列表和社交媒体链接有它们自己的像素宽度。
为了确定头部内元素的百分比值，我遵循了Ethan的公式，以940像素的整个头部宽度作为我的上下文。
Logo: 240 ÷ 940 = .255319148 Hosts: 436 ÷ 940 = .463829787 Social media links: 90 ÷ 940 = .09574468
然后，我将每个值都转换为百分比，并用于我的CSS声明中。
1. #logo a {
2. width: 25.5319148%; /* 240px / 940px */
3. }
4. #hosts {
5. width: 46.3829787%; /* 436px / 940px */
6. }
7. #push {
8. width: 9.574468%; /* 90px / 940px */
9. }
请注意，对于所有这些值，我从不向上取整百分比。计算得到的确切值需要用于CSS。在任何浏览器（包括Internet Explorer）中，我都没有遇到过这些长百分比的任何问题。
另外请注意，在我的每个百分比值之后，我都包含了注释，显示原始像素值（目标）和上下文值，这是一个非常有用的开发参考。
正确设置上下文
将宽度值转换为百分比的过程很简单……只要你的数学是正确的。更具体地说，只要你引用了正确的上下文。
在少数情况下，我的计算没有得到正确的百分比显示。每一次，这种情况都发生在我使用了错误的上下文值作为公式的参数。
正如图 3所示，主持人信息是一个定义列表（<dl>），其中包含宽度各不相同的元素（<dt>、<dd>、<a>等）。
当我最初进行计算时，我使用了960像素的头部（见图 2）作为上下文。所以，对于<dt>的宽度，我计算了
116 ÷ 960 = .120833333
然而，得到的百分比（12.0833333%）并没有提供我需要的尺寸。直到我意识到我的上下文不同时，我才得到了正确的百分比值。
对于<dt>，上下文实际上是父级<dl>，宽度为436像素。这改变了我的计算，并给了我所需的百分比。
116 ÷ 436 = .266055045
如果你在百分比值上遇到问题，请先检查你是否使用了正确的上下文值。这将为你节省头痛和时间。
比例字体
我为 ee-podcast.com 实现灵活性的下一步是使用比例字体。这本质上与比例宽度是相同的概念：使用比例值而不是固定的像素值。对于字体，首选的比例值是em。
要计算比例em，你使用相同的公式（目标 ÷ 上下文 = 结果）。对于字体，上下文是基础字体，通常在body元素上声明。
1. body {
2. font: 100%/1.5 "Open Sans", Arial, Helvetica, sans-serif;
3. }
大多数现代浏览器的基线字体是16像素，所以如果你使用上面的例子，字体大小是100%，那么你的字体大小的上下文是16px。
让我们考虑主持人姓名链接的字体大小，在EE Podcast Photoshop样稿中是12px。要获得em值，使用公式12 ÷ 16 = .75。当你处理字体时，结果不需要转换为百分比。它就是包含在CSS中的确切em值。
1. #hosts dd {
2. font-size: .75em; /* 12px / 16px */
3. }
比例内边距和外边距
对于内边距和外边距，神奇的公式保持不变。让我们以主持人信息中的<dt>（图 3）为例，它的右外边距是20像素。要获得此外边距的百分比值，我使用与宽度相同的公式。
20 ÷ 436 = .04587159
将小数点向右移动两位，就得到了我的CSS的百分比值。
1. #hosts dt {
2. margin-right: 4.5871559%; /* 20px / 436px */
3. width: 26.6055045%;/* 116px / 436px */
4. }
内边距也是如此。
以 ee-podcast.com 的主要容器为例（见图 4），它们的宽度是940像素，并且左右两侧也各有40像素的水平内边距。要获得内边距的比例值，我将我的目标（20px）除以我的上下文（436px）。
1. header, footer, .wrap {
2. padding-right: 4.25531%; /* 40px / 940px */
3. padding-left: 4.25531%; /* 40px / 940px */
4. width: 79.3%;
5. }
特殊例外
水平内边距的公式有一个特殊的例外：上下文始终是元素本身的宽度，而不考虑父元素的宽度。
例如，头部中的社交媒体链接（图 5）都有25像素的左内边距，以便显示图标。
计算此内边距的比例值时，只参考元素的宽度（90px）作为上下文，即使父元素是940px（图 2）。
25 ÷ 90 = .277777777
这给了我的CSS内边距以下百分比。
#push li a {
padding-left: 27.7777777%; /* 25px / 90px */
}
垂直值
到目前为止，我们一直严格处理水平值——也就是说，左侧和右侧。然而，对于内边距和外边距，你可能需要同时指定x轴和y轴的值，这意味着你的上下文会根据你指定的水平值或垂直值而变化。
正如你在迄今为止的所有计算中所见，水平百分比值的上下文是父元素的宽度（内边距是个例外）。而垂直em值，其上下文是基线字体。
如果你还记得比例字体计算， ee-podcast.com 的基线字体是16px。所以，如果我想指定垂直外边距或内边距，我将16px作为上下文。此外，垂直值以em为单位指定，而不是百分比——就像比例字体值一样。
该站点的<header>和<footer>都有垂直内边距：<header>有20px的顶部内边距，而<footer>有20px的底部内边距。（见图 4。）
为了确定这些内边距属性的比例值，我使用相同的公式，并确保指定16px（基线字体）作为上下文。
20 ÷ 16 = 1.25
请记住，当你处理垂直值时，你处理的是em。这意味着你的公式结果不需要转换为百分比。只需在CSS中列出确切的值即可。
1. header, footer, .wrap {
2. padding: 1.25em 4.25531%; /* TB- 20px/16px | RL- 40px/940px*/
3. width: 79.3%;
4. }
在这个例子中，对于每个轴上的内边距值，我使用了内边距简写，并且我还稍微修改了我的注释，以提供更好的开发参考。
1. padding: 1.25em 4.25531%; /* TB- 20px/16px | RL- 40px/940px*/
在这些注释中，我用TB-前缀表示顶部和底部计算值，而用RL-前缀表示右侧和左侧值。这只是我用来帮助我记住我用来获得这些值的计算方法。你使用的格式或语法取决于你，但我强烈建议你花时间注释你的计算。
比例高度
在我一般的开发过程中，我很少指定高度值。然而，在EE Podcast网站上有一些情况我不得不这样做。例如，<header>的高度是148px。
要获得比例高度值，我遵循与垂直值相同的方法：上下文是基线字体。所以，<header>高度的计算是
148 ÷ 16 = 9.25
这个结果以em为单位指定，是我添加到CSS中的。
1. header {
2. height: 9.25em; /*148px / 16px*/
3. padding: .4375em 4.25531% 0; /* T- 7px/16px | RL- 40px/ 940px */
4. }
灵活的图片
EE Podcast网站没有很多内联图片，只有少量的背景图片。我还没有决定网站上图片的处理方式。因此，我无法详细说明我的过程。
我能做的就是分享一些我目前正在参考的资源，以帮助我决定在这个特定网站上拥有灵活图片是否必要。
- 对于背景图片，我想看看background-size属性是否会有用。
- 对于内联图片，max-width方法在浏览器支持方面比较好，并且可以与overflow一起使用。
独特的工作流程
现在我已经讨论了使 ee-podcast.com 灵活的过程，我应该提到，我将该网站视为一个个人项目，所以我只在有时间的时候进行开发。因此，我遵循的过程是迭代的。我从固定宽度开始，然后慢慢地使网站变得灵活，大约花了四个月的时间（并且在深入研究其中的数学时非常小心）。
对我来说，这导致了一个独特的工作流程：
- 我首先使用直接从Photoshop样稿中提取的固定宽度值来开发网站。
- 接下来，我将所有元素的宽度值转换为百分比，但主要容器的宽度除外，它仍然是固定的940像素。
- 然后我将我所有的字体大小转换为比例em。
- 接下来，我将所有垂直外边距和内边距转换为百分比，并将所有水平外边距和内边距转换为比例em。
- 最后，我将我的主要容器的940像素宽度转换为百分比。
我为什么遵循这个过程？主要是因为，作为一个灵活布局的新手，我首先想确保我能够用已知的像素值来构建核心布局（并在所有浏览器上都能很好地工作）。我的逻辑是，我可以慢慢地使事物比例化并进行测试，同时了解我的基线（固定宽度版本）是什么样的。
此外，网站在完成这个过程之前就上线了。所以，我把它分解成可管理的块，我可以在本地测试并在确保新值如我预期一样工作后发布。
我不会计划以后继续遵循这个工作流程，因为它最终花费了更多的时间（很多更多的时间）。对于我下一次灵活布局的尝试，我计划一开始就编写比例值。
但是这个工作流程确实给了我一个宝贵的教训：你可以在同一个布局中混合使用固定值和比例值而不会出现任何问题（只要你的数学是正确的）。如果你和我一样，对转向比例值感到紧张，你可以采取和我一样的循序渐进的方法：依赖你已知的像素值，然后迭代地将它们替换为比例值。
下一步是什么？
虽然灵活的布局完成了网站在分辨率变化时重排和调整的大部分繁重工作，但 ee-podcast.com 仍然需要媒体查询。唉，一个灵活流畅的布局本身并不能实现响应式设计。
看看图 6。这显示了在24英寸台式机（1910 x 1200分辨率）上完全灵活的 ee-podcast.com。一切都是比例的，但一些小地方可以改进以提供更舒适的观看体验，例如缩小logo和主持人列表之间的间距。
类似地，正如图 7所示，在此分辨率下，行长开始变得难以阅读。
在较小的分辨率下，会出现其他问题。图 8显示了在iPad（纵向模式）上1024 x 768分辨率的网站。比例缩放提供了帮助，但浮动元素的排列方式有问题，需要解决对齐问题，以及许多其他小调整。正如你所看到的，主持人信息出现在logo下方，Google日历和.ics下载链接也出现了类似的问题。
在iPhone（纵向，320 x 480分辨率）上，比例缩放导致了糟糕的阅读体验，正如你在图 9中看到的。
这些问题就是媒体查询发挥作用的地方，因为它们允许你为不同的设备和分辨率提供不同的样式。（如果你没有听我之前的建议，请去阅读《使用CSS3媒体查询响应不同设备》）。与此同时，我在我的主要容器上设置了max-width和min-width的固定像素值，这使得网站受到限制，直到我有空闲时间来部署这些媒体查询。
1. header, footer, .wrap {
2. …
3. min-width: 940px;
4. max-width: 940px;
5. }
媒体查询资源
当涉及到媒体查询时，我比写ScriptJunkie文章时做得更好了，这要归功于许多（对我而言）新工具和资源。
- 想在各种分辨率下查看你的媒体查询吗？试试Screenfly。它并不完美，但我发现它非常非常有用。
- Zoe Gillenwater（她写了迄今为止我找到的最好的CSS3资源）最近整理了“制作高质量媒体查询的基本注意事项”。
- 为Internet Explorer 6到8提供max-width和min-width CSS3媒体查询支持的坚如磐石、轻量级的Polyfill：Respond.js。
调整到正确的思维模式
对我来说，开发EE Podcast网站灵活性的目标是响应式设计。而为我的自由职业网站添加媒体查询的目标也是响应式设计。最终，在这两个网站上我都没有完全实现我的目标。还没有。我从这两种经历中都学到了，任何一种方法本身都不能实现响应式设计。
响应式设计不是流式网格。响应式设计不是媒体查询。响应式网页设计是一种思维模式、一种工作流程、一个宏观概念，它不能（也不应该）被分割成它的各个部分。特别是当有诸如移动优先设计和新流程等考量因素时。
更多资源
有很多值得思考的东西。还有更多的事情要做。这里有一些资源可以帮助你：
- "响应式网页设计"，来自A Book Apart。
- "我爱响应式设计，但是……"
- "移动优先的响应式网页设计在哪里？"
- "An Event Apart: 响应式设计师的工作流程"
这篇文章由Emily Lewis撰写。Emily Lewis是一位自由网页设计师，属于标准主义者，这意味着她对语义化标记、CSS、可用性和可访问性等事物充满热情。作为她传播标准好消息的持续追求的一部分，她在她的博客“A Blog Not Limited”上撰写关于网页设计的文章，是《Microformats Made Simple》的作者，也是《HTML5 Cookbook》的贡献作者。她也是Web Standards Sherpa、.net magazine和MIX Online的特约撰稿人。
除了热爱与网络相关的一切，Emily还热衷于社区建设和知识共享。她联合创办并联合管理Webuquerque（新墨西哥州网页专业人士Adobe用户组），并且是The ExpressionEngine Podcast的联合主持人。Emily还在全美各地的会议和活动中发表演讲，包括SXSW、MIX、In Control、Voices That Matter、New Mexico Technology Council、InterLab和新墨西哥大学。
在以下平台找到Emily：
- Twitter - @emilylewis
- Emily的博客
- Emily Lewis Design