今日完成：

关于响应式网页设计
比较常见的实践是用多种分辨率来测试一个网站，然后添加越来越多的媒体查询规则来修补网站在这些分辨率下出现的问题。然而对于今后的CSS改动来说，每个媒体查询都会增加成本，而这种成本是不应轻易上升的。未来每次对css代码的修改都要求我们逐一核对这些媒体查询是否需要配合修改，甚至可能要求我们反过来修改这些媒体查询的设置。这一点常常被我们忽略，后患无穷。你添加的媒体查询越多，你的CSS代码就会变得越来越经不起折腾。
这并不是说媒体查询是一种不良实践。只要用对了，它就是利器。但是，你只应该把它作为最后的手段。比如你想把网站 做的弹性灵活，但其他尝试全都失败了；或者我们希望在较大或较小的视口下完全改变网站的设计形态（譬如，把侧栏改成水平布局）。这么说的原因在于，媒体查询不能以一种连续的方式来修复问题。它的工作原理基于某几个特定的阶梯（亦称“断点”），如果大部分样式代码并不是以弹性的方式编写，那么媒体查询能做的只是修补某个特定分辨率下的问题————这本质上只是把灰尘扫到地毯下面而已。

当然，有一点上面并没有提到，媒体查询的断点不应该由具体的设备来决定，而应该根据设计自身来决定。这不仅是因为我们的网站需要面向的设备太多了（尤其是考虑到未来的设备时），还因为一个网站在桌面端可能会以任意尺寸的窗口来显示。如果你有信心自己设计在任何可能出现的视口尺寸下都能良好工作，谁关心这些设备的分辨率具体是多少呢？

下面还有一些建议，可能会帮你避免不必要的媒体查询。
1、 使用百分比长度来取代固定长度。如果实在做不到这一点，也应该尝试使用与视口相关的单位（vw、vh、vmin和vmax），它们的值解析为视口宽度或高度的百分比。
不妨考虑在你的媒体查询中使用em单位取代像素单位。这能让文本缩放在必要时触发布局的变化。
2、当你需要在较大分辨率下得到固定宽度时，使用max-width而不是width,因为它可以适应较小的分辨率，而无需使用媒体查询。
3、不要忘记为替换元素（比如 img 、object、video、iframe等）设置一个max-width,值为100%。
4、假如背景图片需要完整地铺满一个容器，不管容器的尺寸如何变化，background-size:cover 这个属性都可以做到。但是，需要时刻牢记——带宽不是无限的，因此在移动网页中通过css把一张大图缩小显示往往是不明智的。
5、当图片（或其他元素）以行列式进行布局时，让视口的宽度来决定列的数量。弹性盒布局（即Flexbox）或者display:inline-block加上常规的文本折行行为，都可以实现这一点。


6、在使用多列文本时，指定column-width(列宽)而不是指定column-count(列数)，这样它就可以在较小的屏幕上自动显示为单列布局。

总的来说，我们的思路是尽最大努力实现弹性可伸缩的布局，并在媒体查询的各个断点区间内指点相应的尺寸。当网页本身的设计足够灵活时，让它变成响应式应该只需要用到一些简短的媒体查询代码。


Basecamp的设计师在2010年写到过这种非常规情况。
“结果我们发现，想让网页在一堆不同的设备上合理显示，只需要在最终产品上添加一点css媒体查询就可以了。这件事请之所以这么简单，关键在于我们的布局原本就是弹性可伸缩的。因此，优化网页在小屏幕的表现，其实只意味着把一些外边距收拢到最小程度，然后把因为屏幕太窄而无法显示成双列的侧栏调整为单列布局而已。”
如果你发现自己需要一大堆媒体查询才能让设计适应大大小小的屏幕，那么不妨后退一步，重新审视你的代码结构。因为在所有的情况下，响应式都不是唯一需要考虑的问题。

明日计划：

完成任务十四的剩余问题

遇到的问题：

无

收获：

无