作者：本·弗莱恩（BenFrain）
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
响应式Web设计HTML5和CSS3实战第2版试读：
前言
响应式Web设计是一种统一的解决方案，可以让Web作品适配手机、平板和桌面电脑。响应式的网站可以适应用户的屏幕大小，为今天和明天的设备都提供最佳用户体验。
本书涵盖响应式Web设计的所有相关内容。不仅如此，通过介绍最新和最有用的HTML5和CSS3技术，还扩充了响应式设计的方法库，让设计变得更简单，更好维护。此外，本书还讨论了编写和交付代码、图片、文件的最佳实践。
只要会用HTML和CSS，就可以学会响应式Web设计。本书内容
第1章，“响应式Web设计基础”，简要介绍响应式Web设计相关的技术。
第2章，“媒体查询”，系统讲解CSS媒体查询，包括它的能力、语法，以及各种使用方式。
第3章，“弹性布局与响应式图片”，展示如何设计比例缩放布局和响应式图片，并对Flexbox布局进行全方位介绍。
第4章，“HTML5与响应式Web设计”，探讨HTML5中的语义元素、文本级语义，以及无障碍方面的考虑，还介绍了如何在网页中添加视频和音频。
第5章，“CSS3新特性”，探讨CSS选择符、HSLA及RGBA颜色、Web排版、视口相对单位，等等。
第6章，“CSS3高级技术”，探讨CSS滤镜、盒阴影、线性与放射渐变、多背影，以及如何为高分辨率设备提供背景图片。
第7章，“SVG与响应式Web设计”，讲述在文档中使用SVG、将SVG作为背影图片，以及通过JavaScript添加交互。
第8章，“CSS3过渡、变形和动画”，看一看使用CSS能够做出哪些交互与动画效果。
第9章，“表单”，在HTML5和CSS3之前，表单一直是个难题，现在不同了。
第10章，“实现响应式Web设计”，阐述在着手实现响应式Web设计时需要考虑的重要因素，并给大家提供一些实用的建议。阅读前提
需要一个文本编辑器
需要一个主流浏览器
喜欢一些无聊的笑话读者对象
你是否需要写两个网站，一个针对手机，一个针对大显示器？或者你已经完成了一版响应式Web设计作品，但不知道怎么把它跟之前的网站集成起来？好，本书可以告诉你想知道的一切。
只需一些HTML和CSS基础就可以轻松看懂这本书，而本书还包含了关于响应式Web设计及优秀网站设计的更多内容。排版约定
在本书中，你会发现一些不同的文本样式，用以区别不同种类的信息。下面是这些样式的一些例子和解释。
正文中的代码、数据库表名、用户输入会以等宽字体进行表示，如：“为了解决前面的问题，可以在网页的
中添加下面这行代码。”代码段格式如下所示：img { max-width: 100%;}
新术语和重点词汇均采用楷体字表示。 这个图标表示警告或需要特别注意的内容。 这个图标表示提示或者技巧。读者反馈
我们总是欢迎读者的反馈。如果你对本书有些想法，有什么喜欢或是不喜欢的，请反馈给我们。这将有助于我们开发出能够充分满足读者需求的图书。
一般的反馈，请发送电子邮件至feedback@packtpub.com，并在邮件主题中包含书名。
如果你在某个领域有专长，并有意编写一本书或是贡献一份力量，请参考我们的作者指南，地址为http://www.packtpub.com/authors。客户支持
现在，你是一位令我们自豪的Packt图书的拥有者，我们会尽全力帮你充分利用你手中的书。下载示例代码
你可以用你的账户从http://www.packtpub.com下载所有已购买Packt图书的示例代码文件。如果你从其他地方购买本书，可以访问http://www.packtpub.com/support并注册，我们将通过电子邮件把文件发送给你。勘误表
虽然我们已尽力确保本书内容正确，但出错仍旧在所难免。如果你在我们的书中发现错误，不管是文本还是代码，希望能告知我们，我们不胜感激。这样做，你可以使其他读者免受挫败，帮助我们改进本书的后续版本。如果你发现任何错误，请访问http://www.packtpub.com/submit-errata提交，选择你的书，点击勘误表提交表单的链接，并输入详细说明。勘误一经核实，你的提交将被接受，此勘误将上传到本公司网站或添加到现有勘误表。从http://www.packtpub.com/support选择书名就可以查看现有的勘误表。侵权行为
版权材料在互联网上的盗版是所有媒体都要面对的问题。Packt非常重视保护版权和许可证。如果你发现我们的作品在互联网上被非法复制，不管以什么形式，都请立即为我们提供位置地址或网站名称，以便我们可以寻求补救。
请把可疑盗版材料的链接发到copyright@packtpub.com。
非常感谢你帮助我们保护作者，以及保护我们给你带来有价值内容的能力。问题
如果你对本书内容存有疑问，不管是哪个方面，都可以通过questions@packtpub.com联系我们，我们将尽最大努力来解决。 第 1 章 响应式Web设计基础
几年前，我们看到的网站还都是固定宽度的，目标是让所有用户都拥有相同的体验。这种固定宽度（通常为960像素左右）对笔记本电脑来说也不算宽，拥有更大显示器的用户则会在两侧看到很大的白边。
2007年，苹果iPhone首次带来了真正意义的手机上网体验，彻底改变了人们上网的方式。
本书第1版曾这么写道：“从2010年7月到2011年7月，短短12个月，全球手机浏览器的使用量就从2.86%飙升至7.02%。”
2015年年中，同一家调查机构（gs.statcounter.com）的数据显示，这个数字已经达到33.47%。北美地区的数字则是25.86%。
不管怎么统计，移动设备的增长都是前所未有的。与此同时，27英寸乃至30英寸的大屏幕显示器如今也成为了司空见惯的东西。这样一来，上网设备屏幕之间的差距也达到了前所未有之大。
面对不断扩展的浏览器和设备，我们还是有应对方案的。这个方案就是基于HTML5和CSS3的响应式Web设计。响应式Web设计可以让一个网站同时适配多种设备和多个屏幕，可以让网站的布局和功能随用户的使用环境（屏幕大小、输入方式、设备/浏览器能力）而变化。
不仅如此，基于HTML5和CSS3的响应式Web设计，并不需要依赖服务端或后端方案。1.1 定义需求
无论你是刚刚接触响应式Web设计、HTML5、CSS3，还是已经对它们很熟悉了，我都希望本章可以实现两个目标。
如果你已经在自己的响应式Web设计中使用了HTML5和CSS3，本章可以帮你快速做一个回顾。如果你是一位新手，可以把这一章看成“新手训练营”，它会告诉你阅读本书所需的一切。
学完本章，你将对实现响应式Web设计有一个全面清晰的了解。
有人会问，既然如此，剩下9章有什么用呢？本章最后也会对此给出答案。
以下是本章的主要内容：
定义响应式Web设计
如何确定浏览器支持程度
工具和文本编辑器
第一个响应式的例子
视口meta标签的重要意义
怎么让图片随窗口缩放
用CSS3媒体查询定义断点
前面例子的不足之处
为什么学习之旅才刚刚开始1.2 什么是响应式Web设计“响应式Web设计”这个名字是Ethan Marcotte在2010年发明的。当时，他在A List Apart上写了一篇文章（http://www.alistapart.com/articles/responsive-web-design/），这篇文章综合运用了三种已有技术（弹性网格布局、弹性图片/媒体、媒体查询）实现了一个解决方案，就叫“响应式Web设计”。响应式Web设计的由来
所谓响应式Web设计，就是网页内容会随着访问它的视口及设备的不同而呈现不同的样式。
最初，响应式设计是从“桌面”、固定宽度设计开始的。然后，到了小屏幕上，内容会重排，或者根据情况隐藏部分内容。可是，随着时间推移，人们发现，还是采用相反的设计思路更好，即先为小屏幕设计内容、样式，然后再向大屏幕扩展。
详细介绍这些情况之前，我们先来看看浏览器支持与文本编辑器/工具。1.3 浏览器支持
由于响应式Web设计已经广为人知，所以跟客户及相关方沟通变得越来越容易。提到“响应式Web设计”，很多人都表示知道怎么回事。而写一个项目就可以满足所有设备的说法也很有竞争优势。
不过，浏览器支持一直是响应式Web设计面临的最大问题。市面上如此多的浏览器和设备，要想一个不落地支持并不现实。有时候是时间问题，有时候是预算问题，有时候两方面问题都有。
一般来说，要支持的浏览器版本越早，想达到现代浏览器中相同功能和效果所需的工作量就越大。因此，最好的做法是先写一个较轻量的代码架构，然后根据所需的体验针对能力更强的浏览器进行扩展，包括视觉和功能。
本书上一版还花了不少篇幅介绍怎么迎合老旧版本的桌面浏览器。但这一版不会在这方面浪费时间了。
在写作这一版的2015年年中，IE6、IE7、IE8基本消失了，就连IE9的市场份额也降到了2.45%（IE10只占1.94%，IE11上升到了11.68%）。如果你必须考虑兼容IE8甚至更低版本，在同情你的遭际之余，我必须坦率地告诉你，这本书里没多少相关的内容可资利用。
对于其他人来说，应该劝告自己的客户或老板，告诉他们为什么给那些“残疾”浏览器写代码是错误的，而把时间和资源主要放在支持现代浏览器和现代平台上才是最明智的。
不过到最后，唯一重要的因素还是你自己。在通常情况下，我们写的网站必须在所有常用浏览器里表现正常。除了基本功能，有必要提前确定针对哪个平台要实现最强的功能，以便对其他平台上的视觉和功能作出相应取舍。
这是非常实际的做法，因为从最简单的“基本”体验开始，逐步扩充（所谓“渐进增强”）更容易。相反，先做出大而全的版本，然后再针对能力不足的平台寻找后备方案（所谓“平稳退化”）则要麻烦得多。
为了进一步说明提前确定主要支持平台很重要，我们举个例子。假设你很倒霉，25%的用户都在用IE9，那你必须考虑这个版本的IE都支持什么特性，然后再相应地剪裁自己的设计方案。同样，如果有大量用户使用的手机平台是Android 2，你也要考虑类似的问题。不同平台需要考虑的“基本”体验相差很大。
如果没有合适的数据，那么我会按照一个简单粗暴的逻辑来决定是否开发某个特定平台/浏览器的版本：如果支持浏览器X的开发成本超过了浏览器X的用户创造的收益，那么就不为该浏览器开发特殊的版本。
能不能适配某个旧平台/版本不是问题，问题在于是否应该去适配它。
在确定哪些平台和浏览器版本支持什么特性时，建议参考这个网站：http://caniuse.com。这个网站的界面简洁，查询方便。关于工具和文本编辑器
用什么文本编辑器或IDE来写响应式网站都一样。如果你觉得某个简单的文本编辑器足够你高效编写HTML、CSS和JavaScript代码，那就行啦。其他工具也一样，没有哪个工具是必需的。只要能让你写HTML、CSS和JavaScript就行。Sublime Text、Vim、Coda、Visual Studio、Notepad，选哪一个都不重要，你喜欢就好。
不过，请大家注意，现在确实出现了不少新工具（通常也是免费的）。这些工具可以把以往需要手工来做的事自动化。比如，CSS预处理器（Sass、LESS、Stylus、PostCSS）可以帮我们组织代码、变量、颜色操作和数学运算。像PostCSS这样的工具可以帮我们完成添加浏览器前缀这样烦琐的任务。另外，一些清理和验证工具可以帮我们检查HTML、CSS和JavaScript代码是否符合标准，自动提示输入错误和语法错误。
新工具始终在不断涌现，而且会不断改进。虽然本书有时会提到一些有用工具的名字，但并不代表对你来说最合适，你应该去找最适合自己的。事实上，本书的示例除了HTML和CSS标准之外，不依赖任何工具。至于怎么利用前端工具让自己的代码更快更可靠，那是你的事。1.4 第一个响应式的例子
本章开头承诺让你在学完这一章之后，了解所有与响应式Web设计相关的知识。前面我们讨论的都是一些相关话题，现在该付诸行动了。 代码示例
下载本书示例代码的地址是：http://rwd.education/download.zip或https://github.com/benfrain/rwd。请注意，下载到的代码只包含每个示例的最终版本。比如，第2章的例子是第2章结束时的状态，而不是该章中间部分的某个状态。1.4.1 HTML
先从HTML5结构讲起。大家先不要着急理解每一行代码的用途（特别是
中的代码），第4章会详细介绍它们。现在，我们只关注
标签中的元素。必须承认，现在的网页看起来一点也不特别，只有几个DIV、一张LOGO图、一张图片（看起来很好吃的松饼）、一两段文本和一个项目列表 。以下是删节后的代码。为简单起见，段落中的文字已经隐藏了，因为我们要关注的只是结构。只要知道那些文字介绍了怎么制作标准的英式松饼就行了。
如果想看完整的HTML文件，请解压下载后的代码。
Scones: the most resplendent of snacks
Occasionally maligned andmisunderstood; the scone is a quintessentially British classic.
Incredible scones, picturefrom Wikipedia
Recipe and serving suggestions follow.
Ingredients
Method
默认情况下，网页布局是弹性的。就它现在这个样子把它打开（还不包含媒体查询），缩放浏览器窗口，你会看见文本会根据屏幕缩放自动重排。
那换个设备怎么样呢？在没有CSS的情况下，iPhone中的效果如下图所示。
在iPhone中也是一个“正常的”网页。这是因为iOS默认会按980像素宽度来渲染网页，然后再把页面缩小呈现在视口当中。
浏览器中用于呈现网页的区域叫视口（viewport）。视口通常并不等于屏幕大小，特别是可以缩放浏览器窗口的情况下。
因此，从现在开始，我们会使用这个准确的术语指代可以呈现网页的区域。
为了解决前面的问题，可以在网页的
中添加下面这行代码：这个视口的标签是一种非标准的（但却是事实标准的）方式，它告诉浏览器怎么渲染网页。在这里，标签想表达的意思是：按照设备的宽度（device-width）来渲染网页内容。事实上，在支持这个标签的设备上给你看一看效果，你就明白了。
不错呀！现在，网页中的文字看起来更有“原生”的感觉了。我们继续。
第2章在介绍媒体查询的时候还会详细讨论标签的更多设置和组合用法。1.4.2 图片
有人说“一图胜千言”，确实如此。我们网页中关于松饼的文字介绍再多，也没有图片有吸引力。下面我们就在页面上方添加一张松饼的图片，效果类似引诱用户往下看的大题图。
哇，真是好大一张图（2000像素宽），它让整个网页看起来都失衡了。不行，必须解决这个问题。可以用CSS给图片指定固定宽度，但问题是我们想让它能在不同大小的屏幕中自动缩放。
比如，我们例子中的iPhone屏幕宽度为320像素，如果我们把图片设置成320像素宽，那么iPhone屏幕旋转后又怎么办呢？这时候320像素变成了480像素。解决方案很简单，只要一行CSS代码就可以让图片随容器宽度自动缩放。
在这里我们创建一个CSS文件：css/styles.css，将它链接到HTML页面的头部。
以下是我们在这个CSS文件中写的代码。一般来说，应该先设置一些默认值，这些话题后面几章我们再讨论。现在我们就加入这点代码：img { max-width: 100%;}
回到手机上，刷新页面，结果比较符合预期了。
这里声明max-width规则，就是要保证所有图片最大显示为其自身的100%（即最大只可以显示为自身那么大）。此时，如果包含图片的元素（比如包含图片的body或div）比图片固有宽度小，图片会缩放占满最大可用空间。 为什么不用width:100%?
要实现图片的自动缩放，也可以使用更通用的width属性，比如width:100%。然而，这条规则在这里的效果不同。如果给width属性设置一个值，那么图片就会按照该值显示，不考虑自身固有宽度。以我们例子中的LOGO（同样也是一张图片）为例，这条规则会导致它显示得跟它的容器一样宽。在容器比图片宽得多的情况下（就像我们这里的LOGO一样），图片会被无谓地拉伸。
很好，现在图片和文本都显示正常了。不管视口多大，至少水平方向上再也没有内容溢出了。
再回过头来在较大的视口中看看效果。下图是在视口宽度大约为1400像素下看到的效果，基本样式下的文本和图片明显被拉长了。
这可不行！事实上，视口宽度达到600像素时，效果就不好了。在这个宽度上，如果我们可以对某些元素进行重排，也许可以有所改进，比如调整图片大小并将其放置在一侧，或修改某些元素的字体大小和背影颜色。
没问题，使用CSS媒体查询可以轻易实现我们说的所有功能。1.4.3 媒体查询
我们知道，当视口宽度超过600像素时，当前的页面布局存在被严重拉伸的问题。下面我们就使用CSS3的媒体查询根据屏幕宽度来调整布局。媒体查询可以让我们在某些条件下（如宽度和高度为多少的情况下）为网页应用样式。 不针对流行的设备宽度设置断点
所谓“断点”，就是某个宽度临界点，跨过这个点布局就会发生显著变化。
人们在刚开始使用媒体查询的时候，经常会针对当时流行的设备设置断点。当时，iPhone（320像素 × 480像素）和iPad（768像素× 1024像素）的宽度决定了断点。
不过，当时那样做并不好，现在来看就更不可取了。这是因为这样实际上把设计跟特定的屏幕大小绑定了。既然是响应式设计，那应该与显示它的设备无关才对，而不是只在某些屏幕中才最合适。
断点应该由内容和设计本身决定。比如你的设计可能在500像素或更宽的时候看起来就不对了，当然也许是800像素。总之，断点应该由你自己的项目设计决定。-
第2章将全面介绍媒体查询，因此“媒体查询”也是那一章的名字。
不过，为了说明如何改进我们的设计，这里可以只关注一种媒体查询，即最小宽度媒体查询。在这个媒体查询中设置的CSS规则，只在视口符合最小定义宽度条件时才会应用到网页。实际的最小宽度可以使用不同的长度单位指定，比如百分比、em、rem和px。在CSS中，最小宽度媒体查询是这样写的：@media screen and (min-width: 50em) { /* 样式 */}
@media指令告诉浏览器这里是一个媒体查询，screen（技术上讲，不需要在这里声明“屏幕”，具体细节请参考下一章）告诉浏览器这里的规则只适用于屏幕类型，而and (min-width: 50em)的意思是其中的规则只适用于视口宽度在50em以上的情况。
Bryan Rieger第一次指出（http://www.slideshare.net/bryanrieger/rethinking-the-mobile-web-by-yiibu）：“没有媒体查询本身就是媒体查询。”
这句话的意思就是，我们在媒体查询外面写的第一条规则，实际上是针对所有媒体的“基本”样式。在此基础上，可以再针对不同能力的设备加以扩展。
现在，只要知道应该以最小屏幕为起点，然后再根据需求渐进扩充视觉和功能即可。针对更大的屏幕做修改
我们知道，视口宽度达到600像素（或37.5rem）时，布局就会显得很难看。下面我们再通过一个例子，来展示怎么根据视口大小实现不同的布局。
基本上所有浏览器默认的文本大小都是16像素，因此用像素值除以16就可以得到rem值。第2章会进一步介绍为什么需要这样做。
首先，不让题图太大，而是把它挪到右侧去。然后把介绍文字放在图的左侧。
然后，再把主要的文本内容，也就是如何制作松饼的方法，放在位于右侧带框线的配料表左下方。
这些样式调整都可以封装到一个媒体查询当中。下图就是调整之后的效果。
完成之后的页面在较小的屏幕上还和以前一样，只是在视口宽度大于50rem时，就会调整为新的布局。
以下是我们添加的布局样式：@media screen and (min-width: 50rem) { .IntroWrapper { display: table; table-layout: fixed; width: 100%; } .MoneyShot, .IntroText { display: table-cell; width: 50%; vertical-align: middle; text-align: center; } .IntroText { padding: .5rem; font-size: 2.5rem; text-align: left; } .Ingredients { font-size: .9rem; float: right; padding: 1rem; margin: 0 0 .5rem 1rem; border-radius: 3px; background-color: #ffffdf; border: 2px solid #e8cfa9; } .Ingredients h3 { margin: 0; }}
还算不错，是吧？只用了少量代码，就让页面实现了对视口宽度变化的响应，为用户呈现了更实用的外观。有了这些媒体查询样式，在iPhone上我们看到的页面如下：
而在50rem宽时，页面效果如下：
添加更多装饰对我们理解什么是渐进增强并没有什么意义，因此这里就省略了。如果你想查看相关代码，可以解压下载的示例代码。
虽然这个例子本身很简单，但它已经涵盖了响应式Web设计的基本方法。
总结一下我们介绍的基本内容。首先是“基本的”样式，它适用于任何设备。在这个样式基础上，我们再为不同视口、不同能力的设备，渐进增加不同的视觉效果和功能。
CSS媒体查询的（3级）规范在这里：https://www.w3.org/TR/css3-media-queries/。
还有一个CSS媒体查询（4级）的草案：http://dev.w3.org/csswg/media-queries-4/。1.5 示例的不足之处
本章介绍了使用HTML5和CSS3实现响应式Web设计相关的所有基本要素。
我们都知道，前面的示例远远不能涵盖我们想要实现的目标，同样也不代表我们只能做到这些。
如果我们想让网页响应环境光线的变化呢？如果我们想在用户使用不同输入设备（手指而不是鼠标）时改变链接大小呢？如果我们想只用CSS实现动画和元素移动效果呢？
还有标记。怎么使用标记来构建页面，才能保证所有元素都具有语义，比如article、section、menu，或者怎么让表单内置支持验证（不需要JavaScript参与）？怎么实现在不同视口中修改元素显示的次序呢？
别忘了图片。这个示例中使用了弹性图片，可是如果用户使用手机查看页面，那么他会下载一个很大的图片（至少2000像素以上），而在屏幕上又只能缩成几分之一显示。这样页面会显得很卡。还有更好的办法吗？
还有LOGO和图标呢。这个示例使用的是PNG图片，但使用SVG（Scalable Vector Graphics，可伸缩矢量图）可以简单地适用各种分辨率。SVG图形看起来非常清晰，无论使用什么屏幕。
好在你还在看这本书，这些问题的答案将在后续章节中陆续揭晓。1.6 小结
收获不小吧，这一章让你了解响应式Web设计相关的所有基本要素。不过，正像我们刚刚说过的，还有很多方面存在不小的改进空间。
其实还不够，因为我们不只想要掌握响应式Web设计的全部技能，更想给用户提供最刺激的体验。所以还得继续学习。
首先，我们必须知道CSS媒体查询的3级和4级标准都提供了哪些特性。我们看到了怎么让网页响应视口宽度变化，但我们可以做的远远不止这一点，稍后还将有更精彩的内容纷至沓来。赶紧翻到下一章去看看吧。 第 2 章 媒体查询
上一章，我们快速地介绍了响应式网页相关的基本要素：弹性布局、弹性图片和媒体查询。
本章详尽介绍媒体查询，希望大家能完全掌握它的能力、语法及未来动向。
本章内容：
为什么响应式Web设计需要媒体查询
媒体查询的语法
如何在link标签、@import语句和CSS文件中使用媒体查询
可供测试的设备特性
使用媒体查询根据屏幕空间大小调整视觉效果
应该把媒体查询写在一块，还是哪里需要写在哪里
理解meta视口标签如何针对iOS和安卓设备启用媒体查询
媒体查询未来可能拥有什么特性
CSS3规范分成很多模块，媒体查询（3级）只是其中一个模块。利用媒体查询，可以根据设备的能力应用特定的CSS样式。比如，可以根据视口宽度、屏幕宽高比和朝向（水平还是垂直）等，只用几行CSS代码就改变内容的显示方式。
媒体查询得到了广泛实现。除了古老的IE（8及以下版本），几乎所有浏览器都支持它。一句话，没有理由不用它！
W3C制定规范要走一个批准流程。如果有空，可以读读他们的官方流程文档：https://www.w3.org/2005/10/Process-20051014/tr。简单来说，所有规范都从WD（Working Draft，工作草案）开始，然后是CR（Candidate Recommendation，候选推荐），接着是PR（Proposed Recommendation，建议推荐），几年后才能成为W3C REC（Recommendation，推荐标准）。处于较成熟阶段的模块，通常使用起来也比较安全。比如，CSS Transforms Module Level 3（http://www.w3.org/TR/css3-3d-transforms/）在2009年3月就进入了WD阶段，但浏览器对它的支持度比处于CR阶段的媒体查询等模块差得多。2.1 为什么响应式Web设计需要媒体查询
CSS3媒体查询可以让我们针对特定的设备能力或条件为网页应用特定的CSS样式。翻开W3C的CSS3媒体查询模块的规范（https://www.w3.org/TR/css3-mediaqueries/），可以看到官方给媒体查询下的定义：“媒体查询包含媒体类型和零个或多个检测媒体特性的表达式。width、height和color都是可用于媒体查询的特性。使用媒体查询，可以不必修改内容本身，而让网页适配不同的设备。”
如果没有媒体查询，光用CSS是无法大大修改网页外观的。这个模块让我们可以提前编写出适应很多不可预测因素的CSS规则，比如屏幕方向水平或垂直、视口或大或小，等等。
弹性布局虽然可以让设计适应较多场景，也包括某些尺寸的屏幕，但有时候确实不够用，因为我们还需要对布局进行更细致的调整。媒体查询让这一切成为可能，它就相当于CSS中基本的条件逻辑。CSS中基本的条件逻辑
真正的编程语言都有相应的语法构造处理一个或多个条件分支。这时候通常指的就是条件逻辑，比如if/else语句。
如果提到编程你就心塞，大可不必！这里要讲的只一个非常简单的概念。日常生活中，你可能会在朋友排队买咖啡时这么跟他说：“如果他们有三重巧克力松饼，给我买一份； 如果没有，就给我买一份胡萝卜蛋糕。”这就是有两种可能结果的条件语句。
在写作本书时，CSS并不支持真正的条件逻辑或可编程特性。循环、函数、迭代和复杂的数学计算仍然只可能在CSS预处理器中看到（我可曾提过一本不错的专门讲Sass预处理器的书——《Sass和Compass设计师指南》?）。不过，媒体查询确实具有在CSS中实现条件逻辑的能力。使用媒体查询，其中的样式只在某些条件具备的情况下才会被应用。 可编程的方式会有的
CSS预处理器的流行已经引起CSS规范编写者的注意。目前已经有了一个关于CSS变量的WD：https://www.w3.org/TR/css-variables/。
不过，现在只有Firefox支持这个建议，因此还不具备普遍意义。2.2 媒体查询的语法
说了那么多，媒体查询的语法是什么样的，还有更重要的，媒体查询怎么起作用呢？
在任何CSS文件的最后输入以下代码，然后打开引用该CSS文件的网页看看效果。如果不想写代码，也可以直接打开本书示例example_02-01：body { background-color: grey;}@media screen and (min-width: 320px) { body { background-color: green; }}@media screen and (min-width: 550px) { body { background-color: yellow; }}@media screen and (min-width: 768px) { body { background-color: orange; }}@media screen and (min-width: 960px) { body { background-color: red; }}
好了，在浏览器中打开网页，缩放窗口并看看效果。页面的背景颜色会随着当前视口大小的变化而变化。稍后我们会介绍这些语法如何起作用。但首先，关键是得知道如何以及在哪里可以使用媒体查询。在link标签中使用媒体查询
从CSS2开始接触CSS的读者都知道，可以在标签的media属性中指定设备类型（screen或print），为不同设备应用样式表。看一个例子（可以把它放在
标签中）：媒体查询更进一步，不仅可以指定设备类型，还能指定设备的能力和特性。可以将其想象为对浏览器的询问。如果浏览器回答“是”，那么就会应用对应的样式表。如果浏览器回答“否”，就不会应用。除了问浏览器：“你是在有屏幕的设备上吗？”（CSS2里只能如此），媒体查询可以问更多细节，比如可以问：“你是在有屏幕的设备上，而且设备是垂直朝向的吗？”下面看看代码：
首先，媒体查询表达式询问了设备的类型（是屏幕设备吗？），然后又询问特性（你的屏幕是垂直方向吗？）。显然，样式表portrait-screen.css会应用给任何有屏幕且屏幕方向垂直的设备，而不符合这两个条件的设备则不会获得其样式。如果在媒体查询表达式的开头添加一个not，就可以把询问的条件反过来。比如，以下代码的结果与前面的例子相反，只会将样式表应用给垂直朝向的非屏幕设备：2.3 组合媒体查询
可以将多个媒体查询串在一起。比如，在前面一个示例的基础上，可以进一步限制只把样式表应用给视口大于800像素的设备：
此外，可以组合多个媒体查询。只要其中任何一个媒体查询表达式为真，就会应用样式； 如果没有一个为真，则样式表没用。下面看代码：
这里有两点需要强调一下。首先，逗号分隔每个媒体查询表达式。其次，在projection（投影机）之后没有任何特性/值对。这样省略特定的特性，表示适用于具备任何特性的该媒体类型。在这里，表示可以适用于任何投影机。
没错，任何CSS长度单位都可以用来指定媒体查询的条件。像素（px）是最常用的，而em或rem也都可以用。要了解这些单位的更多信息，可以参考我的一篇文章：http://benfrain.com/just-use-pixels。
假设你想在800像素处设置断点，但又想用em单位，可以用800除以16，就是50em。2.3.1 @import与媒体查询
可以在使用@import导入CSS时使用媒体查询，有条件地向当前样式表中加载其他样式表。比如，以下代码会导入样式表phone.css，但条件是必须是屏幕设备，而且视口不超过360像素：@import url("phone.css") screen and (max-width:360px);
记住，使用CSS中的@import会增加HTTP请求（进而影响加载速度），因此请慎用。2.3.2 在CSS中使用媒体查询
前面我们介绍在了
标签中引入CSS文件，以及通过@import引入CSS文件时使用媒体查询，这两种方式都是链接样式的场景。但更常见的是在CSS文件内部直接使用媒体查询。比如，如果把以下代码包含进一个样式表，它会在屏幕设备的宽度为400像素及以下时把所有h1元素变成绿色：@media screen and (max-device-width: 400px) { h1 { color: green }}首先使用@media规则声明这是一个媒体查询，然后指定匹配的设备类型。在前面的例子中，我们想把后面的样式应用给屏幕设备（而不是打印设备，即print）。然后在后面的括号中，进一步指定查询条件。最后，跟编写其他样式一样，把CSS规则写在一对花括号中。
此时此刻，我得敬告各位：多数情况下，并不需要指定screen。为什么呢？大家看规范是怎么说的：“在针对所有设备的媒体查询中，可以使用简写语法，即省略关键字all（以及紧随其后的and）。换句话说，如果不指定关键字，则关键字就是all。”
因此，除非你真的想针对特定的媒体类型应用样式，否则就不要写screen and了。后面的例子都会这么做。2.3.3 媒体查询可以测试哪些特性
在响应式设计中，媒体查询中用得最多的特性是视口宽度（width）。就我个人的经验来看，很少需要用到其他设备特性（偶尔会用到分辨率和视口高度）。不过，为以防万一，这里还是给出了媒体查询3级规定的所有可用特性。但愿其中有些特性能引起你的兴趣。
width：视口宽度。
height：视口高度。
device-width：渲染表面的宽度（可以认为是设备屏幕的宽度）。
device-height：渲染表面的高度（可以认为是设备屏幕的高度）。
orientation：设备方向是水平还是垂直。
aspect-ratio：视口的宽高比。16∶9的宽屏显示器可以写成aspect-ratio:16/9。
color：颜色组分的位深。比如min-color:16表示设备至少支持16位深。
color-index：设备颜色查找表中的条目数，值必须是数值，且不能为负。
monochrome：单色帧缓冲中表示每个像素的位数，值必须是数值（整数），比如monochrome: 2，且不能为负。
resolution：屏幕或打印分辨率，比如min-resolution: 300dpi。也可以接受每厘米多少点，比如min-resolution: 118dpcm。
scan：针对电视的逐行扫描（progressive）和隔行扫描（interlace）。例如720p HD TV（720p中的p表示progressive，即逐行）可以使用scan: progressive来判断； 而1080i HD TV（1080i中的i表示interlace，即隔行）可以使用scan: interlace来判断。
grid：设备基于栅格还是位图。
上面列表中的特性，除scan和grid外，都可以加上min或max前缀以指定范围。看看下面的代码：@import url("tiny.css") screen and (min-width:200px) and (maxwidth:360px);
这里使用最大宽度（max-width）和最小宽度（min-width）设定了范围。因此，tiny.css只在设备视口介于200像素和360像素之间时才会被应用。 CSS媒体查询4级中废弃的特性
CSS媒体查询4级草案中废弃了一些特性，特别是device-height、device-width和device-aspect-ratio（参见：https://drafts.csswg.org/media-queries-4/#mf-deprecated）。虽然已经支持它们的浏览器还会继续支持，但不建议在新写的样式表中再使用它们。2.4 通过媒体查询修改设计
从原理上讲，位于下方的CSS样式会覆盖位于上方的目标相同的CSS样式，除非上方的选择符优先级更高或者更具体。因此，可以在一开始设置一套基准样式，将其应用给不同版本的设计方案。这套样式表确保用户的基准体验。然后再通过媒体查询覆盖样式表中相关的部分。比如，如果是在一个很小的视口中，可以只显示文本导航（或者用较小的字号），然后对于拥有较大空间的较大视口，则通过媒体查询为文本导航加上图标。
现在我们就看一个实际的例子（example_02-02）。首先是标记：HeartsClubsSpadesDiamonds
接下来是CSS：.CardLink { display: block; color: #666; text-shadow: 0 2px 0 #efefef; text-decoration: none; height: 2.75rem; line-height: 2.75rem; border-bottom: 1px solid #bbb; position: relative;}@media (min-width: 300px) { .CardLink { padding-left: 1.8rem; font-size: 1.6rem; }}.CardLink:before { display: none; position: absolute; top: 50%; transform: translateY(-50%); left: 0;}.CardLink_Hearts:before { content: "?";}.CardLink_Clubs:before { content: "?";}.CardLink_Spades:before { content: "?";}.CardLink_Diamonds:before { content: "?";}@media (min-width: 300px) { .CardLink:before { display: block; }} 下载示例代码
如果你在Packt出版社购买了本书，可以登录你的账号下载本书示例代码：http://www.packtpub.com。如果你是在别处买的，请访问：http://www.packtpub.com/support，然后注册并通过电子邮箱接收示例代码。
小视口下的效果如下图所示：
以下则是大视口中的效果：2.4.1 任何CSS都可以放在媒体查询里
要知道，正常情况下我们编写的任何CSS样式，都可以放在媒体查询里。因此，使用媒体查询可以从整体上修改一个网站的布局和外观（通常针对不同的视口大小）。2.4.2 针对高分辨率设备的媒体查询
媒体查询的一个常见的使用场景，就是针对高分辨率设备编写特殊样式。比如：@media (min-resolution: 2dppx) { /* 样式 */}
这里的媒体查询只针对每像素单位为2点（2dppx）的屏幕。类似的设备有iPhone 4的视网膜屏，以及其他很多高清屏的安卓机。减小dppx值，可以扩大这个媒体查询的适用范围。
为支持更广泛的设备，在使用min-resolution属性时，需要加上适当的浏览器前缀，可以使用工具自动完成。不知道什么是浏览器前缀？下一章我们会详细介绍。2.5 组织和编写媒体查询的注意事项
在这里，我们插一部分，谈谈在编写和组织媒体查询的时候都有哪些方式方法。这些方式方法各有利弊，但至少我们应该知道它们，至于是否采用，那就是另一回事了。2.5.1 使用媒体查询链接不同的CSS文件
从浏览器的角度看，CSS属于“阻塞渲染”的资源。换句话说，浏览器需要下载并解析链接的CSS文件，然后再渲染页面。
不过，现代浏览器都很聪明，知道哪些样式表（在头部通过媒体查询链接的样式表）必须立即分析，而哪些样式可以等到页面初始渲染结束后再处理。
在这些浏览器看来，不符合媒体查询指定条件（比如屏幕比媒体查询指定的小）的CSS文件可以延缓执行（deferred），到页面初始加载后再处理，以便让用户感觉页面加载速度更快。
关于这方面内容，可以参考谷歌开发者网站的文章“阻塞渲染的CSS”
http://www.zfanw.com/blog/）中文翻译版，这里引用的文字直接采用了他的译文。——译者注" class="dd-footnote" id="(.*)" src="../Images/note.png"/>：https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css（短链接：http://t.cn/Rqn0XEt）。
我想重点向大家介绍这一段：“请注意，「阻塞渲染」仅是指该资源是否会暂停浏览器的首次页面渲染。无论CSS是否阻塞渲染，CSS资源都会被下载，只是说非阻塞性资源的优先级比较低而已。”
再强调一次，所有链接的文件都会被下载下来，只是如果有的文件不必立即应用，那浏览器就不会让它影响页面的渲染。
因此，如果浏览器要加载的响应式页面（参见example_02-03）通过不同的媒体查询链接了4个不同的样式表（分别为不同视口的设备应用样式），那它就会下载4个CSS文件，但在渲染页面之前，它只会解析那个针对当前视口大小的样式表。2.5.2 分隔媒体查询的利弊
编写多个媒体查询分别对应不同的样式表虽然有好处，但有时候也不一定（不算个人喜好或代码分工的需要）。
多一个文件就要多一次HTTP请求，在某些条件下，HTTP请求多了会明显影响页面加载速度。Web开发可不是件容易的事儿！此时应该关注的是网站的整体性能，最好在不同设备上对不同的情形都做相应测试，比较之后再决定。
我对这件事的看法是，除非有充裕的时间让你去做性能优化，否则我一般都不会指望在这方面获取性能提升。我会首先确认：
所有图片都压缩过了；
所有脚本都拼接和缩短了；
所有资源都采用了gzip压缩；
所有静态内容都缓存到了CDN；
所有多余的CSS规则都被清除了。
之后，我才可能会考虑，为了再提升一些性能，是否需要把媒体查询分隔开，让它们分别引用不同的CSS文件。
gzip是一种压缩和解压缩的文件格式。主流一点的服务器都支持gzip压缩CSS，从而让服务器发送给设备的文件明显“瘦身”（到了设备之后，再解压缩成原来的格式）。关于gzip的更多信息，请参考维基百科：https://en.wikipedia.org/wiki/Gzip。2.5.3 把媒体查询写在常规样式表中
除非在极端情况下，否则我都建议在既有的样式表中写媒体查询，跟常规的规则写在一起。
如果你也是这样想的，那么还有一个问题需要考虑：是该把媒体查询声明在相关的选择符下面，还是该把相同的媒体查询并列起来，每个媒体查询单独一块？这个问题问得好啊。2.6 组合媒体查询还是把它们写在需要的地方
我个人喜欢把媒体查询写在需要它的地方。比如，我想根据视口大小在样式表中的几个地方改变几个元素的宽度，我会这样做：.thing { width: 50%;}@media screen and (min-width: 30rem) { .thing { width: 75%; }}/* 这里是另外一些样式规则 */.thing2 { width: 65%;}@media screen and (min-width: 30rem) { .thing2 { width: 75%; }}
这样写看起来有点蠢，两个媒体查询的条件相同，都针对屏幕最小宽度为30rem的情况。像这样重复写两遍@media真的是冗余和浪费吗？难道不该把针对相同条件的CSS规则都组织到一个媒体查询块里吗？像这样：.thing { width: 50%;}.thing2 { width: 65%;}@media screen and (min-width: 30rem) { .thing { width: 75%; } .thing2 { width: 75%; }}
当然这也是一种方式。不过，从维护代码的角度看，这种写法不
试读结束[说明：试读内容隐藏了图片]