> 原文出处：http://www.w3cplus.com/responsive/responsive-images-part-10-conclusion.html 我们做到了！我们到了[响应式图片101系列](http://www.w3cplus.com/blog/tags/509.html)的结尾。 在与这个系列就此分别之前，我想给出一些提示，资源和一些关于响应式图片发展的最终思考。 ## 响应式图片审查 本来在这个系列里，我想添加一章响应式图片审查的内容。这是我们开始把页面图片转换成响应式图片时做的第一件事。 很有可能下一步就是使用你学到的东西并应用在页面上。 幸运的是，我最近详细书写了审查内容。所以没有在101系列中重复，我鼓励你阅读我写的关于[响应式图片审查](http://blog.cloudfour.com/responsive-images-audits/)的文章。 ## 兼容性 响应式图片标准的浏览器支持在快速发展。到2015年8月，Chrome，Opera和Firefox都支持了 [`picture`](http://caniuse.com/#feat=picture), [`srcset`](http://caniuse.com/#feat=srcset), [`sizes`](http://caniuse.com/#feat=picture), 和[`type`](http://caniuse.com/#feat=picture). Microsoft Edge和Safari支持带有显示描述符(`x`)的[`srcset`](http://caniuse.com/#feat=srcset)，但不支持宽度描述符。Microsoft已经开始了支持所有响应式图片标准的[开发](http://dev.modern.ie/platform/status/pictureelement/?filter=f3f0000bf&search=picture)。 Apple还没有支持该标准，但是[Apple清楚支持响应式图片很重要](https://twitter.com/grorgwork/status/616333173362786304)并且[Yoav Weiss](http://blog.yoav.ws/)已经在给Webkit实现做贡献。 对于[`image-set()`](http://www.w3cplus.com/responsive/responsive-images-101-part-8-css-images.html)，还有做[很多工作](http://caniuse.com/#search=image-set)。 ## PictureFill 然而即便当前所有浏览器都支持响应式图片标准，我们仍然需要一个方法让老版本浏览器兼容新语法。这时候就需要用到[PictureFill](https://scottjehl.github.io/picturefill/) [polyfill](https://en.wikipedia.org/wiki/Polyfill)。 PictureFill让你现在就可以使用新响应式图片语法。 ## 自动化图片处理流程 在[第9部分里](http://www.w3cplus.com/responsive/responsive-images-101-part-9-image-breakpoints.html)，我说人们不应该手动选择图片断点。应该让软件自动帮我们完成。 我希望在这一点上扩展并且在响应式图片的情况下大部分事情通常程度上不是设计师和开发者应该考虑的。 大多数组织的目标应该把图片缩放当作中心并且尽可能自动处理响应式图片。 理想情况下，解决[分辨率切换](http://www.w3cplus.com/blog/tags/509.html)情况的响应式图片工作流应该如下所示： * 当情况允许，使用分辨率无关的SVG图片。 * 当创建或修改设计模版时，模版作者在模版中提供多种图片的[`sizes`](http://www.w3cplus.com/responsive/responsive-images-101-part-5-sizes.html)属性。 * 带[宽度描述符的`srcset`属性](http://www.w3cplus.com/responsive/responsive-images-101-part-4-srcset-width-descriptors.html)由服务器来插只入剩下一些轻松的工作例如给每张图片选择图片断点。 * 内容作者不需要担心。他们唯一的职责是上传可用的最高质量图片然后让图片缩放服务处理其他事情。 这不是遥远的场景。许多组织已经有了图片缩放服务。如果你的组织还没有，我有一个可供参考的[图片缩放服务和工具的电子表格](https://docs.google.com/spreadsheets/d/1e4qdGEoq7tqDCnY7iSSnl3OFoWkzhRfVAly-73A3uCc/edit)（确保同时阅读了[说明博文](http://blog.cloudfour.com/image-resizing-services/)）。 许多内容管理系统开始寻找包含响应式图片的方法。[响应式图片讨论组（RICG）](http://responsiveimages.org/)维护一个[WordPress插件](https://wordpress.org/plugins/ricg-responsive-images/)并且他们正在[研究如何整合到WordPress核心里](https://make.wordpress.org/core/2015/08/25/responsive-image-support-update/)。Drupal 8会自带[响应式图片模块](https://api.drupal.org/api/drupal/core!modules!responsive_image!responsive_image.module/8)（[更多细节](https://www.drupal.org/project/picture)）。 这些图片缩放服务需要扩展的一点是计算出对于给定图片需要添加多少图片源并且输出这些图片源的标记。如果使用了[服务器提示](https://tools.ietf.org/html/draft-grigorik-http-client-hints-03)它们甚至不需要担心标记。 但是无论怎么自动化，我相信以图片缩放和处理为中心对于保持思路清晰非常重要。当我们谈到探索响应式图片的新公司时，需要评估的第一件事情是它们的图片工作流以及多大程度可以实现自动化。 ## 响应式图片未来 我们才刚刚开始探索响应式图片。已经有成千上万的网站更新到了新图片标准。许多组织需要更新处理图片的方式来集中和自动化目前仍然是手动完成的工作。 虽然我们面前还有许多工作，似乎我们终于在下坡路了。我们不再需要与寻找每个人都同意的解决方案做斗争。浏览器支持正逐步实现。PictureFill帮我们弥补漏洞。 现在网页开发讨论组开始研究如何实现这些新标准，这意味着我们可以开始互相学习。 如果你已经阅读了[整个101系列](http://www.w3cplus.com/blog/tags/509.html)，那么你就已经有了开始使用响应式图片的所有东西。我对于你会使用新标准做什么已经迫不及待了。请分享你所学到的！ 感谢阅读。

> 原文出处：http://www.w3cplus.com/responsive/responsive-images-101-part-9-image-breakpoints.html 我其实很害怕写[响应式图片101系列](http://www.w3cplus.com/blog/tags/509.html)里图片断点这个部分。选择图片断点每个人都会遇到，坦白说，我也没有一个好的解决方案。 但我们迟早会遇到图片断点的问题。所以不妨现在就开始研究。 ## 响应式图片断点是什么？ 在响应式布局中，断点代表在某个视口尺寸上改变页面的布局或功能。通常与媒体查询相对应。 响应式图片断点与此类似但有细微差别。当我在思考图片断点时，我会尝试回答两个问题： * 需要提供多少个图片源来包含此图片需要使用的场景？ * 在哪里以及什么时候应该使用这些图片？ 这些问题的答案产生的断点会与响应式布局中标准的断点不同。在布局中，我遵循Stephen Hay的好方法：改变浏览器大小直到页面看起来很糟糕那么这个时候啊哈，我们需要一个断点。 然而在[艺术指导](http://www.w3cplus.com/responsive/responsive-images-101-definitions.html)中，需要多个图片源的原因和图片在什么浏览器尺寸下看起来很糟糕并无关系。我们想提供多个图片源是基于表现考虑，不同尺寸屏幕的分辨率等其他原因。 因此我们不能在图片上机械重复使用响应式布局断点。或者我猜也许是可以，但是如果这样做的话，那就和我们使用响应式图片的初衷背道而驰了。 ## 艺术指导的图片断点相对简单 在[艺术指导使用情况中](http://www.w3cplus.com/responsive/responsive-images-101-definitions.html)，艺术指导本身会告诉我们需要多少个图片源并且什么时候应该使用。 回顾Nokia浏览器网页的例子，我们可以知道图片应该在什么时候从风景模式转为肖像模式。发生转换时，需要一个新图片源。 然而，这也许只是图片的一部分。如果艺术指导的某一张图片包含了大范围的尺寸呢。我们会发现仍然需要与艺术指导切换不对应的多个图片源。 可以在[第8部分](http://www.w3cplus.com/responsive/responsive-images-101-part-8-css-images.html)提到的Shopify首页看到看到这个例子。  虽然图片只有一个主要的艺术指导切换变化－从全尺寸的图片变成裁剪的版本－Shopify仍然提供了6个图片源说明图片尺寸和显示器分辨率。 ~~~ <picture> <source srcset="homepage-person@desktop.png, homepage-person@desktop-2x.png 2x" media="(min-width: 990px)"> <source srcset="homepage-person@tablet.png, homepage-person@tablet-2x.png 2x" media="(min-width: 750px)"> <img srcset="homepage-person@mobile.png, homepage-person@mobile-2x.png 2x" alt="Shopify Merchant, Corrine Anestopoulos"> </picture> ~~~ 了解图片在艺术指导使用情况下的表现让我们得到一些结论，但仍然没法回答关于必要图片断点的所有问题。 ## 分辨率切换断点 这就是事情变得有技巧的地方。至少艺术指导给了我们一些关于需要多少图片源的提示。 当拉伸自适应图片时，它们总是表现良好。不能指望它们表现变差来告诉我们什么时候需要改变图片源。 来看一下分辨率切换的例子：  在这里例子中，当前页面视口尺寸中一张Michelle Obama的照片的尺寸为`400px x 602px`。这张图片的最大尺寸要在`2000px x 3010px`的分辨率下才会显示。最大文件的大小为`250K`。 可以直接缩放这张`2000px`的图片，并且它会表现良好。但是尺寸过大。如果提供一个小版本的图片例如分辨率`800px x 1024px`会显得更好。图片尺寸仅为`73K`。 我们都同意当页面中图片尺寸仅为`400px x 602px`时，提供一张分辨率为`800px x 1024px`大小为`73K`的图片会比下载最大尺寸的图片更好。 但为什么要止步于800×1204呢？  如果我们提供另一张尺寸为`600px × 903px`的图片源，大小只有`42K`。这比`800px × 1024px`大小的图片节约了`31K`（`42％`）。 很棒。`42%`的空间节约是很大的进步。也许我们应该更进一步。如果是`500px`宽呢？`450px`宽呢？  每个更小尺寸的图片都可能比之前的尺寸更节约空间。如果继续这种方式，最终会达到页面上这张图片的精确尺寸。 那么这里有一个令人困扰的关于图片断点的问题。如何确定当前页面使用的图片尺寸的文件大小太大了呢？ 答案是除非图片源完全匹配图片显示在页面上的尺寸，否则它总是过大的。总是有机会提供更小尺寸的图片来优化。 ## 为什么不提供精确的图片尺寸呢？ 在这一点上，你也许会疑惑为什么不直接提供在页面中使用图片的精确尺寸呢。 首先，响应式设计中设定自适应图片断点的目的是让图片随着视口改变而伸缩。如果提供页面中使用图片的精确尺寸，不论是视口尺寸改变还是设备旋转都需要下载新图片。 其次，提供任何能想到尺寸的图片是不可能的。是的，我们可以动态改变图片尺寸，但与此同时，服务器需要处理这些工作就会拖慢分发图片到浏览器的速度。 因此，大多数网站把图片缓存在内容分发网络（CDN）上。要把每个尺寸的图片缓存在CDN上是非常昂贵的。 最后，[浏览器在开始下载时并不知道页面中图片的确切尺寸](http://www.w3cplus.com/responsive/responsive-images-101-part-4-srcset-width-descriptors.html)。这就是最初让我们制定响应式图片新标准的原因。 ## 选择图片断点的可行方法 像开始提到的那样，我没有绝对可靠的关于如何选择需要图片源数量的方案。相反，我想阐述一些看待这个问题的不同方式来帮助你做决定。 ## 让它飞起来（又叫做，匹配布局的断点） 你团队中的某些人会说，“嗨，你觉得这些产品图片需要多少图片源？” 你犹豫了一会儿说，“3个怎么样？小，中，大。” 如果你已经这么做了也不要羞涩。我很确定现在大部分使用响应式图片的人已经这么做了。 也许你的考量中需要兼容手机，平板和桌面也就是小，中，大屏幕。 或者你考虑到图片会显示的范围并估计一下。也许你只是简单看一下主流的断点数量然后决定同样处理图片断点。 我完全理解。显然这比给所有视口提供一张大图片要好。 当然如果我们的决定更有逻辑会更好。 ## 测试响应式图片 可能猜测听起来也不是很奇怪，让我们在选择图片断点中加入一些科学成分。我们来看一些响应式图片并计算出它们需要多少断点。 这件事情最难的部分是限制响应式图片，或计算出总共有多少个图片。 对于一些网站，所有照片可能按照品牌有特定样式。如果是这种情况，很容易找到具体的有代表性的图片。选择一些图片改变尺寸并保存最大和最小图片间的尺寸直到你认为已经得到了合适的范围。 当然，如果你的网站有多种多样的图片样式，找到具有代表性的图片几乎是不可能的。 ## 内存消耗对图片断点分布的影响 今年夏天早些时候，[Tim Kadlec](http://timkadlec/)发表了一个关于[手机图片过程](https://www.youtube.com/watch?v=jP68rCjSSjM)的演讲。在这个演讲中，他主要研究了响应式设计中自适应图片的内存开销。 Tim展示了随着图片增大，改变图片尺寸的影响也变大了。  在上述例子中，在每个方向上将一张`600px × 600px`的图片减少`50px`会导致`230000b`的浪费相比于用同样方式将`200px × 200px`减少`50px`只有`70000b`的浪费。 这一点给我们提供了一些选择断点的参考。并不是要使断点均匀分布，在图片变大时应该增加更多断点。  不幸的是，虽然这一点告诉我们大尺寸图片需要更多断点，我们依然不知道具体在哪里需要这些断点。 ## 基于绩效预算设置图片断点 如果我们把绩效预算的灵感应用到响应式图片？这样会看起来如何呢？ 我们给浪费的比特数定义一定数量的预算，浏览器下载适应当前页面的图片时可以在这范围内造成一定的比特浪费。 因此我们决定每个响应式图片的绩效预算为`20K`。这意味着必须确保定义的各种图片源都小于`20K`。 这样做后，我们发现图片断点基于视觉多样性发生了巨大的改变并且使用了压缩。 让我们来看三张样例图片。 ### 时代广场－8个图片断点  这张图片的视觉多样性丰富。颜色和纹理变化意味着无法在保证图片质量的情况下进行很大程度的JPEG无损压缩。 因此，这张图有8个图片断点－以20k为间隔设置－最小图片尺寸为（`320×213`），最大图片尺寸为（`990×660`）。 | Breakpoint # | Width | Height | File Size | | --- | --- | --- | --- | | [1](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-320x213.jpg) | 320 | 213 | 25K | | [2](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-453x302.jpg) | 453 | 302 | 44K | | [3](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-579x386.jpg) | 579 | 386 | 65K | | [4](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-687x458.jpg) | 687 | 458 | 85K | | [5](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-786x524.jpg) | 786 | 524 | 104K | | [6](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-885x590.jpg) | 885 | 590 | 124K | | [7](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square-975x650.jpg) | 975 | 650 | 142K | | [8](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/times-square.jpg) | 990 | 660 | 151K | ### 凯特林的早晨－3个图片断点  不像时代广场的图片，这张图片很多地方颜色非常相似并且纹理很少。因此，JPEG能更好得压缩这张图片。 在一张能被良好压缩的图片上，20K的预算可以更进一步。对于这张图片，我们只需要三个图片断点来覆盖这张图片会使用的所有尺寸区间。 | Breakpoint # | Width | Height | File Size | | --- | --- | --- | --- | | [1](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/kettering-sky-320x213.jpg) | 320 | 213 | 9.0K | | [2](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/kettering-sky-731x487.jpg) | 731 | 487 | 29K | | [3](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/kettering-sky.jpg) | 990 | 660 | 40K | ### 微软logo－1个图片断点**  这是一张简单的PNG8文件。最大尺寸（`990×660`）的大小仅为`13K`。因此，它不用做任何改变就适合我们的`20K`预算。 | Breakpoint # | Width | Height | File Size | | --- | --- | --- | --- | | [1](http://www.w3cplus.com/sites/default/files/blogs/2015/1510/Microsoft_Logo.png) | 990 | 660 | 13K | 来看一下我们创建的[样例页面](http://cloudfour.com/examples/image-breakpoints/)上的其他图片。了解断点数量如何变化即便所有图片开始时分辨率相同且最终断点相同。 现在，我并没有建议大家手动决定每个图片的断点。但是未来你可以在服务器上声明20K的响应式图片预算然后让服务器计算每张图片的图片源数量。 我过去已经写过了更多关于[响应式图片的绩效预算](http://blog.cloudfour.com/sensible-jumps-in-responsive-image-file-sizes/)内容的细节。如果你最终施行了这个方法，请告诉我。 ## 基于请求的频繁程度设置图片断点 最近的[响应式图片讨论组（RICG）](http://responsiveimages.org/)中，[Yoav Weiss](http://blog.yoav.ws/) 和 [Ilya Grigori](https://www.igvita.com/)讨论了一个基于图片尺寸请求的频繁程度来选择图片断点的方式。 对于在Akamai工作的Yoav和在Google工作的lily来说，他们对于多图片的一个共同问题在于把这些源都存在[边缘服务器](http://www.nczonline.net/blog/2011/11/29/how-content-delivery-networks-cdns-work/)上然而存储空间通常有限制并且代价更加昂贵。 不光是像Akamai和Google这样的公司想要减少边缘服务器上存储的图片数量，它们内容分发网络的整个目的都是减少人们耗费在web页面渲染上的时间。 因此，如果能够把请求最频繁的图片尺寸缓存在边缘服务器，它们会给大多数用户带来最快的分发体验。 对于这些组织，他们可以把图片处理和断点逻辑与分析系统联系起来并且一旦发现新的图片尺寸被更频繁得请求后便改变图片的尺寸。 当把它与Ilya已经实现新[HTTP客户端提示](https://tools.ietf.org/html/draft-grigorik-http-client-hints-03)特性结合起来时，服务器对于如何在CDN上保存图片会变的非常聪明，这样做的话很少需要设计师和开发来做决策。 ## 人们不应该手动去做 我相信在短短几年内，没有人会再谈论选择响应式图片断点因为没有人会再手动去做。 当然，我们仍然会对艺术指导使用情况的图片作出决定，但即便是这个情况，我们当然不会给每个图片源做决定。我们只处理需要介入的部分然后让图片处理服务解决剩余部分。 根据绩效预算或不同尺寸的请求频繁程度来选择图片源都有一大堆好处。但这些解决方案作为手动工作流的一部分都站不住脚。 未来，我们的工作流也许是将最高品质的图片上传到内容管理系统或图片处理系统并且再也不要关心。 [这个系列](http://www.w3cplus.com/blog/tags/509.html)一开始有9个部分，但是讨论响应式图片时总有许多要说。最后补允一篇，用来总结响应式图片的使用。

> 译文出处：http://www.w3cplus.com/responsive/responsive-images-101-part-8-css-images.html > 英文原文：http://blog.cloudfour.com/responsive-images-101-part-8-css-images/ 大多数时候谈到响应式图片，人们指的是内联图片，而不是CSS图片。 这是因为在`<picture>`和`srcset`之前内联响应式图片还没有好的解决方案。但遇到CSS图片时，我们可以使用媒体查询，那还有什么可担心呢？ 现在是时候回顾响应式CSS图片并基于我们已经学过的内联图片寻找解决方案。 ## 分辨率切换的解决方案`image-set()` 与我们正在研究的内联图片一样，首先需要考虑的问题是当前的情况是[分辨率切换](http://www.w3cplus.com/responsive/responsive-images-101-definitions.html)还是[艺术指导](http://www.w3cplus.com/responsive/responsive-images-101-definitions.html)。 对于分辨率切换来说，我们需要尽可能给浏览器提供选择并让浏览器选择可能最佳的图片。浏览器基于用户配置，网站环境等因素能够知道哪张图片可能最适合。 要给浏览器提供选项，我们应该使用[`image-set()`语法](http://www.w3cplus.com/css/safari-6-and-chrome-21-add-image-set-to-support-retina-images.html)。  你也许会注意到`image-set()`和`srcset`之间的一些联系。事实上，`srcset`是仿照`image-set()`的。 ~~~ background-image: image-set( "foo.png" 1x, "foo-2x.png" 2x); ~~~ 与`srcset`类似，`image-set`的值包含逗号分隔的图片`URL`列表以及屏幕分辨率描述符。如果没有提供屏幕分辨率描述符，默认为`1`倍。 然而`image-set()`仍不支持宽度描述符。计划是改善`image-set()`来提供与`srcset`等价的特性。 虽然你看到大部分`image-set()`例子都是用在`background-image`上，它其实可以用在任何可以使用图片的CSS属性上。 ## image-set()：被遗忘的响应式图片标准 `image-set()`是第一代响应式图片规范语法，正如本文所提到的那样，它是`srcset`的基础。 然而，因为普遍使用媒体查询解决CSS响应式图片问题，`image-set()`几乎被所有人忽视了。响应式图片研究小组没有花很多时间来讨论它。浏览器没有优先支持它。 当`<picture>`和`srcset`的标准几乎完成后，我们环顾四周意识到需要重新协商`image-set()`，于是我们已经开始增强`image-set()`的功能并把它嵌入`srcset`。 众所周知，虽然`image-set()`是第一个响应式图片标准，但是它依然缺乏浏览器支持。在Chrome，Opera和Safari中[添加webkit前缀可用](http://caniuse.com/#search=image-set)。Firefox和Microsoft都还没有支持。 那么为什么我们要在[响应式图片101系列](http://www.w3cplus.com/blog/tags/509.html)里提到呢？ 因为`image-set()`是分辨率切换的正确解决方案。当`image-set()`被广泛支持时，面对分辨率切换的情况我们应当使用它[而不是带媒体属性的`<picture>`元素](http://blog.cloudfour.com/dont-use-picture-most-of-the-time/)，原因与使用带媒体属性的`<picture>`相同。 直到`image-set()`被广泛支持前，你还是会使用CSS艺术指导方案来解决分辨率切换。 ## 艺术指导 艺术指导的CSS解决方案是什么呢？媒体查询。 这很简单，事实上我假定你已经对媒体查询有所了解因此没有提供语法样例。 但是请听我说，请确保图片的媒体查询没有重叠否则会导致重复下载图片。如果有任何疑问，查看Tim Kadlec的[媒体查询和资源下载结果](http://timkadlec.com/2012/04/media-query-asset-downloading-results/)。 ## 分辨率媒体查询 如果你想在高分辨率屏幕下支持艺术指导，那肯定想用分辨率媒体查询。  分辨率媒体查询让你可以针对满足定义分辨率的设备屏幕添加特定CSS规则。 ~~~ @media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) {/* High density stuff here */} ~~~ （非常感谢CSS Tricks提供[语法样例](https://css-tricks.com/snippets/css/retina-display-media-query/)。） 上述语法中你首先会注意到的是我们加入了包含`-webkit`前缀的媒体查询。这是为了支持老`device-pixel-ratio`语法的机器。只有一台机器支持这个带`-webkit`前缀的语法所以只列出了一台。 更近一步的语法是分辨率媒体查询。在我们的例子中，我们用了最小分辨率，但是正如你猜到的那样，当然有最大分辨率这个功能可以使用。 分辨率媒体查询可以检查以下三种情况： * **`dip`**:点每英尺 * **`dpcm`**:点每厘米 * **`dppx`**:点每像素 前两个单位很直观，对于`dppx`我有写疑惑。Mozilla网络开发文档这样[定义`dppx`](https://developer.mozilla.org/en-US/docs/Web/CSS/resolution)： > 这个单位代表每像素单位上点的数目。因为CSS中`in`与`px`的比例固定为`1:96`，`1dppx`等于`96dpi`，这与CSS中由图片分辨率定义的默认图片分辨率显示有关。 有一点疑惑？刚开始看到我也是这样。 我是这样想的，`1x`,`2x`,`3x`等都基于不明确的定义。一些设备上`1`倍的值与其它设备不同因为一些设备的分辨率是`72dpi`或`96dpi`以及其它。 然而从CSS的角度看，这些差异无关紧要。CSS工作组决定了CSS中`in`与`px`的比例固定为`1:96`。 因此，虽然`72dpi`和`96dpi`的博弈导致`1`倍的定义不明确，`1ppx`是大家都认同的“`1`倍”。 你也许会问，`1`倍为什么对于`srcset`和`image-set`那么重要，对于最小分辨率来说，还有必要使用`dppx`吗？ 我不知道。我只知道你可以把`1dppx`当做`1`倍，`2dppx`当做`2`倍，以此类推。在这一点上，我刚刚才接受了这个差异并决定继续向前看。我推荐你也这么做。;-) ## 来到最难的部分 信不信由你，响应式图片的语法其实是简单的部分。在下一节里，我们将讨论选择图片断点的巨大挑战。

> 译文出处：http://www.w3cplus.com/responsive/responsive-images-101-part-7-type.html > 英文原文：http://blog.cloudfour.com/responsive-images-101-part-7-type/ 到目前为止我们专注于如何提高响应式图片性能。这是必要的，但是今天，我们依然在页面上使用一样的旧图片。 现在，是时候看点有意思的东西了！ ## Type属性 你是否为可选的可靠图片格式仅限于`jpg`,`png`和`gif`的事实而悲哀？是否对新图片格式例如`svg`或`webp`的浏览器支持性而感到好奇？ 如果是，你会喜欢`type`属性。  `type`属性可以添加在`<picture>`元素中的`<source>`元素上并且允许声明可供浏览器选择的不同图片类型： ~~~ <picture> <source type="image/svg+xml" srcset="logo.xml"> <source type="image/webp" srcset="logo.webp"> <img src="logo.png" alt="ACME Corp"> </picture> ~~~ 这个新`type`属性模仿了`<video>`元素的类型属性并且使用起来差不多。 浏览器会选择支持的被声明的图片类型中的第一个源。如果没有识别出任何源的类型，它会用`<img>`元素的`src`或`srcset`声明。 在`srcset`属性中声明的图片格式的值为`MIME`类型。如果有多个图片`URL`，它们必须都匹配声明的图片`MIME`类型。 当然，你可以把`type`和[`sizes`](http://www.w3cplus.com/responsive/responsive-images-101-part-5-sizes.html)单独结合或者再加上[`media`](http://www.w3cplus.com/responsive/responsive-images-101-part-6-picture-element.html)属性。这三个属性都可选并且可以结合完成任何功能。 所有`<source>`元素都需要`srcset`属性。[屏幕密度](http://www.w3cplus.com/responsive/responsive-images-101-part-3-srcset-display-density.html)和[宽度描述符](http://www.w3cplus.com/responsive/responsive-images-101-part-4-srcset-width-descriptors.html)都可以和`type`属性结合使用。 ## 你需要媒体属性吗？ 我已经习惯告诉人们在[大多数响应式图片上不应该用`<picture>`元素](http://www.w3cplus.com/responsive/(http://blog.cloudfour.com/dont-use-picture-most-of-the-time/))。这一点是真的但又有一些误导性。 既然你正在快速学习所有的内联响应式图片技术，让我们来分解一下： * 网页上多数图片适用于[分辨率切换使用情况](http://www.w3cplus.com/responsive/responsive-images-101-definitions.html)。 * 当遇到分辨率切换使用情况，人们想让浏览器做出最佳选择。这就是`srcset`的设计用途。 * 当使用带有媒体属性的`<picture>`元素时，其实是在制定浏览器应该使用的图片。 因此，当需要处理分辨率切换和多图片格式支持时应该使用`<picture>`。关闭媒体属性让浏览器自己处理。 ## 图片格式的渐进增强 到目前为止，我想在保持这个系列专业度的同时让大家感觉轻松。但是到此为止了因为。。。 天呐！天呐！天呐！（重要的事情说三遍）TYPES让我太激动了！ 诶，必须把它移出我的系统。 许多年来我们都想要使用不同的图片格式，但总是需要等待这个格式被广泛传播和接受。 但即便最终是时候切换了，我们都知道这样做会放弃老版浏览器。这是一个过程但我们希望不要影响太多人。也许正是因为害怕流失用户我们才从来没有切换新的图片格式。 但是`<picture>`元素加上`type`属性让我们摆脱了这个难题。我们可以在图片格式上使用渐进增强来处理。 Sara Soueidan叙述了她如何开始使用[SVG并把PNG做为备用方案]((http://sarasoueidan.com/blog/svg-picture/)而不是过去所用的那些hacks。 然而图片格式不仅仅有SVG和webp。JPEG-2000呢？JPEG-XR？APNG? 如果你能找到支持某一种图片格式的浏览器并相信这能对用户产生一定价值，那就没有理由使用那些备用的格式。 ### JPEG-2000 Zoltan Hawryluk写的一篇[非常有深度的文章](http://www.w3cplus.com/responsive/(http://www.useragentman.com/blog/2015/01/14/using-webp-jpeg2000-jpegxr-apng-now-with-picturefill-and-modernizr/))让我眼界大开，我从中了解了不同图片格式的优点尤其是带`alpha`透明的JPEG-2000图片。 在Zoltan文章里的一个例子中，他展示了[多颜色背景上放置的一个骰子](http://www.w3cplus.com/responsive/(http://www.useragentman.com/tests/html5ImageConverter/examples/dice-compare/drag-test.html))。为了实现这个效果需要`alpha`通道透明度。  图片的文件尺寸如下： | 分辨率| JPEG 2000 | JPEG-XR | PNG | WEBP | | --- | --- | --- | --- | --- | | 320×240 | 2K | 22.6K | 55.2K | 112.1K | | 600×450 | 13.5K | 48.5K | 14.3K | 26.6K | | 1024×768 | 19.2K | 95.7K | 325.7K | 56K | 请看一下节约的空间。尺寸为`1024*768`大小的PNG格式的筛子文件大小为`325.7k`。相同图片的JPEG-2000格式的大小仅为`19.2K`。不可思议！ 我知道你在想什么。这虽然很棒，但是没有浏览器支持JPEG-2000。 我也这么认为，但我错了。桌面版和移动端Safari已经支持JPEG-2000。 在将所有图片转换为JPEG-2000之前，注意Zoltan的警告： > 正如你所看到的，JPEG-2000图片的数量。可选图片的文件尺寸很大程度依赖于原始图片的特性。因此有时候可选图片格式的结果更好，有时候并不是。 所以这将取决于图片和设计。但是你将看到，取决于图片类型，对于那些受浏览器支持的用户这将带来巨大的好处。 ## 图片格式的全新世界 我不指望每个人都马上开始使用JPEG-2000。在这个方向上仍有许多工作要做从而让我们知道哪种图片格式是有意义的，在什么时候应该使用。 使用工具转换而直接得到多种图片格式很难。Zoltan在文章底部的[他使用的创建不同图片格式的工具](http://www.w3cplus.com/responsive/(http://www.useragentman.com/blog/2015/01/14/using-webp-jpeg2000-jpegxr-apng-now-with-picturefill-and-modernizr/))中给出了一些信息。 除了命令行工具，我发现其他工具都很难用。除了一些公司像Adobe有丰富的图片支持例如JPEG-2000外其他公司很少有支持因为之前没人能使用。 还有很多实验要做。我快等不及了！ ## 那CSS呢？ 目前为止我们谈到的所有东西都是内联响应式图片。因为CSS中已经有了媒体查询，内联响应式图片是最大的挑战所以我们大部分注意力都放在它上面。 然而由于在CSS中有很多响应式图片新标准并且有一些你应该知道的技巧。我们将在第八节中继续阐述**CSS响应式图片**。

> 译文出处：http://www.w3cplus.com/responsive/responsive-images-101-part-6-picture-element.html > 英文原文：http://blog.cloudfour.com/responsive-images-101-part-6-picture-element/ 在第[3](http://www.w3cplus.com/responsive/responsive-images-101-part-3-srcset-display-density.html)，[4](http://www.w3cplus.com/responsive/responsive-images-101-part-4-srcset-width-descriptors.html)，[5](http://www.w3cplus.com/responsive/responsive-images-101-part-5-sizes.html)部分中，我们专注于分辨率切换的解决方案。现在是时候来研究如何解决[艺术指导](http://www.w3cplus.com/responsive/responsive-images-101-definitions.html)了。 `<picture>`元素——尤其是媒体属性——被设计来简化艺术指导。  `<picture>`元素包含一系列`<source>`子元素后跟着需要的`<img>`元素。`source`元素原理和`video`元素的子源类似。 ~~~ <picture> <source media="(min-width: 900px)" srcset="cat-vertical.jpg"> <source media="(min-width: 750px)" srcset="cat-horizontal.jpg"> <img src="cat.jpg" alt="cat"> </picture> ~~~ 每个源必须有一个`srcset`属性，可选属性包括`media`，`sizes`和`type`。`<source>`元素上的`sizes`和`srcset`的使用和`<img>`上完全一样。 我们现在主要研究`media`属性。 ## media属性 `media`属性的值是媒体查询。与`sizes`属性的媒体情况不同，这里的媒体查询是你熟知并喜爱的且功能完整。 当浏览器检查`source`元素列表时，使用第一个媒体查询匹配的源。如果没有媒体查询匹配，则使用`<img>`元素。 ## media属性是指令，而不是建议 不像是`srcset`和`sizes`，当使用媒体属性，你在告诉浏览器应该使用哪个源。 浏览器无法自由选择一个不同源。它必须使用第一个媒体属性匹配当前浏览器状况的第一个`<source>`元素。 这就是带有媒体属性的`<picture>`元素非常适合艺术指导的原因。在艺术指导的使用情况中，设计师必须确保在特定视口尺寸下使用的图片与他们预期的一致否则设计可能会被破坏。 让我们来实际看一下。 ## 实际情况下的picture元素 [Shopify](http://www.shopify.com/) 使用`<picture>`元素来解决艺术指导的问题。Shopify’s在主页上突出了一个顾客，Corrine Anestopoulos，Biko Jewelry的联合创始人。  在狭窄的屏幕上，Anestopoulos小姐的照片被裁减。因为图片不再是被简单缩小，这就是考虑到艺术指导的情况。 Shopify使用的标记将`<picture>`元素和`srcset`显示密度描述符结合。我为了简化标记而移除了冗长的图片路径并总结如下： ~~~ <picture> <source srcset="homepage-person@desktop.png, homepage-person@desktop-2x.png 2x" media="(min-width: 990px)"> <source srcset="homepage-person@tablet.png, homepage-person@tablet-2x.png 2x" media="(min-width: 750px)"> <img srcset="homepage-person@mobile.png, homepage-person@mobile-2x.png 2x" alt="Shopify Merchant, Corrine Anestopoulos"> </picture> ~~~ **注：新改版的页面代码：** ~~~ <picture class=""> <!--[if IE 9]><video style="display: none;"><![endif]--> <source srcset="muttonhead-feature@desktop-a97f32476dec8ace5bff5581de852720.png 1x, muttonhead-feature@desktop-2x-9dfadafd12daaa37357521b5cfeb71c9.png 2x" media="(min-width: 990px)"> <source srcset="muttonhead-feature@tablet-098c9c293a9fc4625c4e3881c293d284.png 1x, muttonhead-feature@tablet-2x-9e850f53007aca09e7c3b58d7b6d2ba1.png 2x" media="(min-width: 750px)"> <!--[if IE 9]></video><![endif]--> <img srcset="muttonhead-feature@mobile-46b2bcd7fba4a422861fece5231085a3.png 1x, muttonhead-feature@mobile-2x-4e12c2522c827b69b53ad706aeaf6ba9.png 2x" alt="Shopify online store" class=""> </picture> ~~~ *缩小你的浏览器窗口大小，你能看到图片的更换过程* 仔细观察这些代码，Shopify使用了三个不同的图片断点。每个断点的图片宽度固定－断点间的宽度转变是跳跃的而不是连续的。 因为图片宽度固定，[`srcset`显示密度描述符]((http://www.w3cplus.com/responsive/responsive-images-101-part-3-srcset-display-density.html)就派上作用。因此对于每个断点来说，Shopify定义了一个`1`倍和一个`2`倍源文件。分解开来如下所示： * **`<source … media="(min-width: 990px)">`**:最大尺寸的图片，Shopify把它称为桌面，是第一个图片源。媒体属性告诉浏览器这个源只有在视口宽度大于或等于`990px`才被使用。 * **`<source … media="(min-width: 750px)">`**:第二个源，“平板”图片，视口宽度大于或等于`750px`时使用。因为第一个源在`990px`时起作用并且浏览器选择匹配的第一个源，第二个源的有效视口宽度范围是`750px`到`989px`。 * **`<img>`**:如果前两个源没有匹配，说明视口宽度一定小于`750px`。这种情况下，会使用`<img>`元素上`srcset`。小屏幕会使用”移动设备”图片。 如果图片宽度自适应而不固定，Shopify本可以使用带`srcset`[宽度描述符](http://www.w3cplus.com/responsive/responsive-images-101-part-4-srcset-width-descriptors.html)的`<picture>`而不是[显示密度描述符](http://www.w3cplus.com/responsive/responsive-images-101-part-3-srcset-display-density.html)。 ## 最后一点小技巧 遇到艺术指导的情况，你会需要`picture`元素。另外`picture`规范的创造者还给网页开发带来了一份最终的大礼。在下一节中，将会向大家介绍图片的新格式相关知识，将带领大家进入图片格式的新世界之中。

> 译文出处：http://www.w3cplus.com/responsive/responsive-images-101-part-5-sizes.html > 英文原文：http://blog.cloudfour.com/responsive-images-101-part-5-sizes/ 上一次我们已经发现了[`srcset`宽度描述符](http://www.w3cplus.com/responsive/responsive-images-101-part-4-srcset-width-descriptors.html)的威力，但他们同时也面临着新挑战－当图片开始下载时浏览器知道的只有视窗尺寸。 现在，是时候认识这篇故事里的英雄了：`sizes`属性。  ## Sizes属性必不可少！ 使用`srcset`宽度描述符时都需要`sizes`属性。 事实上，`sizes`只有在使用宽度描述符时才有意义。如果使用显示密度描述符的话，就不需要`sizes`属性。因为浏览器会不知道如何处理它。 ### Sizes语法 最初，在所有响应式图片的新标准中，sizes是我最难想通的一个属性。  像`srcset`一样，`sizes`属性包含一个逗号分隔的列表。这个逗号分隔列表描述了根据视口而变化的图片尺寸。 我要重申这点因为这是理解`sizes`属性的关键。 我们告诉浏览器多大尺寸的图片与多大尺寸的视窗相关。并且能让浏览器知道根据视口尺寸的变化它们之间的关系如何变化。 ~~~ <img src="cat.jpg" alt="cat" srcset="cat-160.jpg 160w, cat-320.jpg 320w, cat-640.jpg 640w, cat-1280.jpg 1280w" sizes="(max-width: 480px) 100vw, (max-width: 900px) 33vw, 254px"> ~~~ 像`srcset`一样，每个由逗号分隔的项目包含两个由空格分隔的值。 ### 媒体情况 第一个值是媒体情况。媒体情况类似于媒体查询，但功能不全，必入，你不能写`@media screen`，但是可以做想要在某个尺寸上做的任何事情。 通常，媒体情况会类似于`(max-width:480px)`或者也许是`(min-width:480px)`。 ### 长度 每个逗号分隔项的第二个值是长度。长度单位通常是视窗宽度（`vw`）。 很有可能你之前没见过`vw`单位。它确实很新，但是在[当今浏览器里已经被广泛支持](http://caniuse.com/#feat=viewport-units)。 每个`vw`单位代表视窗宽度的`1%`，那么`100vw`就是`100%`视窗宽度而`33vw`就是`33%`视窗宽度。 长度不一定要用视窗宽度单位。长度可以是任何长度单位包括绝对和相对长度。你甚至可以用CSS `calc()`来动态计算`margin`。 ### 浏览器如何选择正确的sizes 浏览器开始读取逗号分隔列表值时，它会获取符合媒体情况的第一个值。 来看一下我们的样例标签和`sizes`属性的顺序。 ~~~ <img src="cat.jpg" alt="cat" srcset="cat-160.jpg 160w, cat-320.jpg 320w, cat-640.jpg 640w, cat-1280.jpg 1280w" sizes="(max-width: 480px) 100vw, (max-width: 900px) 33vw, 254px"> ~~~ 翻译成的指令的符号列表，结果如下： * **`(max-width: 480px) 100w`**：视窗等于或小于`480px`，图片是`100%`视窗宽度。 * **`(max-width: 900px) 33w`**：视窗等于或小于`900px`，因为之前的媒体情况这个规则永远不会生效。因此，规则生效意味着视窗宽度为`481px`到`900px`。视窗宽度从`901px`宽到无限大的情况下，图片宽度为`254px`。 * **`254px`**：当前没有媒体情况列表，在没有其他媒体情况满足的情况下长度为默认值。在这种情况下，媒体情况要包含尺寸为`900px`的视窗。因此，视窗宽度从`901px`到无限大，图片宽度为`254px`。 为了帮助大家形成概念，我制作了一段视频，关于Walmart Grocery网站上的值如何随着视口尺寸扩大而变化。 *注：视频需要翻墙才能浏览。* **注意：**在本文发布时，Walmart Grocery网站没有使用`srcset`和`sizes`。这些都是假设的标记。想要实际观察`srcset`和`sizes`，请访问最近才开始使用`srcset`和`sizes`的[The Guardian](http://theguardian.com/)。 ## 如果把内容和表现分离呢？ 我看到许多关于响应式图片新规范的吐槽。大多数人抱怨其复杂性而忽视事实上网页中的图片本来就很复杂以及[WWIC]((http://www.ftrain.com/wwic.html)的一些变化。 但是有一个吐槽我个人非常赞同，现在我们在标签上添加信息表示——**图片尺寸**。我好奇是否有任何一个参与响应式图片标准制定的人在某种程度上提出过这种担忧。 不幸的是，这是不可避免的。像在[第4部分](http://www.w3cplus.com/responsive/responsive-images-101-part-4-srcset-width-descriptors.html)中谈到的那样，浏览器在不知道页面图片尺寸的情况下就开始下载图片资源了。 唯一支持预加载和确保下载正确资源的方式是在标签中提供图片尺寸信息。 ## 预加载究竟值的吗？ 如果你像我一样思考，也许会怀疑预加载会带来那么多问题的话那它本身还有价值吗？ 有。绝对有。  Andy Davies[写了一篇文章](http://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/)关于使用预加载后Google和Firefox在平均页面加载速度上分别提升了`20%`和`10%`。Steve Souders认为“预加载是浏览器实现的[单个最佳的表现改进](http://www.stevesouders.com/blog/2013/04/26/i/)。” 我们不能简单把网页的优秀表现归功于响应式图片。 因此，我们需要找到一个平衡点。`sizes`属性就是平衡点。它提供给浏览器完成工作的恰当信息。 ## Srcset和sizes ＝ 智能浏览器 `srcset`和`sizes`提供了所有在分辨率切换情况下需要的功能。它给浏览器提供恰当的信息来让浏览器做出明智的决定。  但是如果你想要更多的控制该怎么办呢？遇到艺术切换该怎么办？我们将在下一节中向大家介绍有关于这方面的知识——**`<picture>`元素**。

> 译文出处：http://www.w3cplus.com/responsive/responsive-images-101-part-4-srcset-width-descriptors.html > 英文原文：http://blog.cloudfour.com/responsive-images-101-part-4-srcset-width-descriptors/ 在[响应式图片101系列教程](http://www.w3cplus.com/blog/tags/509.html)中的[第三篇中](http://www.w3cplus.com/responsive/responsive-images-101-part-3-srcset-display-density.html)，我们学习了显示密度描述，并且总结出它们适合用于固定宽度图片，但是对于自适应图片有所不足。 伸缩使图片就需要用到`srcset`的宽度描述符。 ## 宽度描述符 宽度描述符的语法与屏幕密度描述符类似。`srcset`属性值是逗号分隔的图片源和描述列表。  区别在于不是用`1x`,`2x`或其他值来表示密度，我们列出了图片源的宽度例如`320w`，`480w`等。 ~~~ <img src="cat.jpg" alt="cat" srcset="cat-160.jpg 160w, cat-320.jpg 320w, cat-640.jpg 640w, cat-1280.jpg 1280w"> ~~~ 图片源的宽度会让人很困惑。宽度描述符会根据分辨率来寻找图片源文件。 换句话说如果在一个图片编辑器中打开一张图片，它的分辨率是多少呢？获取图片的宽度放置在`srcset`属性中。 ## 浏览器选择最佳图片资源 当使用宽度描述符，你给浏览器提供了一系列图片以及它们的真实宽度,因此浏览器可以选择最佳图片源。浏览器是怎么做的呢？ 你的第一反应一定是浏览器检查页面上元素的尺寸并与图片列表尺寸对比。这有点道理，但实际上并不是这样。 我们来看，当浏览器开始下载图片时，通常它并不知道页面中图片的尺寸。 ## 浏览器预加载和合理资源下载 如果查看浏览器渲染页面的时间线，你会发现一些引人注目的事情。  就在浏览器下载HTML后不久，它继续请求CSS和JavaScript。但是在CSS和JavaScript完成下载前，浏览器开始下载图片。 因为CSS和JavaScript都没下载完成，浏览器下载图片时并不知道页面布局。由于不知道布局，它就不知道图片元素的尺寸。 顺带一提，预加载行为正是为什么[我们不能用CSS或JavaScript解决内联响应式图片的原因](http://www.brucelawson.co.uk/2015/why-we-cant-do-real-responsive-images-with-css-or-javascript/)。在浏览器开始下载时它们还不可用。 浏览器唯一知道的是视窗尺寸。一旦我们过渡到了显示密度选择符，一切都与视窗尺寸紧紧相关。 ## 为什么影响呢？ 视窗是真实图片尺寸的抽象替代品。用[Walmart’s Grocery](http://delivery.walmart.com/)页面上的图片作为例子：  在小视窗下，图片几乎和视窗宽度尺寸相同。 然而在大屏幕中，情况不同：  在第二个例子里，视窗宽度为`1540px`，但是图片宽度只有`254px`。知道视窗尺寸不足以给浏览器提供选择合适图片源的信息。 ## 尺寸属性来解决! 我们如何让浏览器知道页面中的图片尺寸，从而让浏览器可以在`srcset`列表中下载正确的图片呢？如何使用图片尺寸属性，欢迎阅读本系列教程的第五部分——**图片尺寸**！

> 译文出处：http://www.w3cplus.com/responsive/responsive-images-101-part-3-srcset-display-density.html > 英文原文：http://blog.cloudfour.com/responsive-images-101-part-3-srcset-display-density/ 自从苹果发布带retina显示屏的iPhone 4，网页设计人员一直在找一个处理高分屏的方案。于是引入了`srcset`和它的显示密度。 ## 使用srcset的切换解决方案 首先提醒大家，显示密度是一种分辨率切换使用情况。当我们解决分辨率切换问题时，我们需要使用`srcset`。 我们想要使用`srcset`的原因是它让浏览器可以选择。当使用`<picture>`元素提供的`media`属性时，实际上我们在告诉浏览器必须使用哪个图片。这对于艺术切换很有效。 遇到分辨率切换的情况时，浏览器知道哪张图片显示效果最好。它可以根据网络情况或用户行为等因素来做决定。 因此除非是艺术切换的情况，我们应该让浏览器本身来自动选择。 ## 显示密度描述 显示密度的语法很直观：  `srcset`属性被添加在`<img>`元素上的。`srcset`的值是一个用逗号分隔的列表。列表中的每个项包含一张图片的路径并且按倍数（例如,`1x`,`2x`,`3x`...）提供多张分辨率的图片。 ~~~ <img src="cat.jpg" alt="cat" srcset="cat.jpg, cat-2X.jpg 2x"> ~~~ 显示密度值`1x`,`2x`等等代表显示密度描述符。如果没有提供显示密度描述，默认是`1x`。 ## 这看起来很简单... 这很简单,试想你需要关心的是显示密度。那么我们会经常碰到吗？ 让我们来看一下[第1部分](http://www.w3cplus.com/responsive/responsive-images-101-definitions.html)中的Apple Watch图片  像之前提到的那样，这张图片是`5144px × 1698px`并且在`2`倍下大小为`398K`。还有一张`1`倍的版本。让我们把它们与[Blackberry Curve 9310](http://us.blackberry.com/smartphones/blackberry-curve-9310.html)上单一分辨率的图片尺寸做对比： | Image | Width | Height | File Size | | --- | --- | --- | --- | | [2x large](http://www.w3cplus.com/sites/default/files/blogs/2015/1509/hero_ygold_edition_large_2x.jpg) | 5144 | 1698 | 398K | | [1x large](http://www.w3cplus.com/sites/default/files/blogs/2015/1509/hero_ygold_edition_large.jpg) | 2572 | 849 | 256K | | [320px, Single Density](http://www.w3cplus.com/sites/default/files/blogs/2015/1509/hero_ygold_edition-320.jpg) | 320 | 106 | 8K | 表格中的最后一行，我把图片大小改变为`320px`宽另存为JPEG从而看看它会怎样。 显然两个尺寸的图片是不够的。当然，我们可以把`320`作为1倍图然后重写标记如下： ~~~ <img srcset="cat.jpg, cat-2X.jpg 2x, cat-3x.jpg 3x, […], cat-16x.jpg 16x"> ~~~ 这会让我们有从`320px`到`5144px`的图片，但我觉得这样很愚蠢。 这就是我认为显示密度描述比其他解决方案不可取的另一个主要原因。我没有任何兴趣来维护一大堆不同显示密度的可用性。 我们难道要提供`1x`,`1.5x`,`2x`,`3x`更多种情况吗？如果算上其他例如iPhone6 Plus的[缩减像素](http://www.paintcodeapp.com/news/iphone-6-screens-demystified)呢？ 有一点我在大家开始用响应式图片时没有提到。如果在多个图片断点上有多个图片密度，有时候就需要重复图片源,因为尺寸很小的2倍图可能与1倍在大的图片断点上是一样的。 很快这样就会变得糟糕。 ## 显示密度描述符最适合固定宽度图片 当你在处理固定宽度图片元素的密度可选时，屏幕密度描述显得很不方便而且存在许多不足。 需要什么来代替呢？本系列的第四部分将会介绍：`Srcset`宽度描述符。

> 译文出处：http://www.w3cplus.com/responsive/responsive-images-101-part-2-img-required.html > 英文原文：http://blog.cloudfour.com/responsive-images-101-part-2-img-required/ 我们需要的响应式图片解决方案的主要原因之一是`<img>`元素功能不足。它只有一个`src`属性，只能加载一张图片资源，但是我们需要加载多个资源。 既然如此，你可能会很惊讶怎么我们还在讨论`<img>`元素而不是其他新东西例如`<picture>`和`srcset`。 不管采用哪种响应式图片方案，**`<img>`元素必不可少**。 `<img>`元素在所有的内联响应式图片解决方案中都饱受诟病。我喜欢把`img`当做一个添加和应用所有响应式图片规则的盒子。  你可以用JavaScript来监控`img`元素上`currentSrc`的变化。下面一段简单的脚本用来监控改变并输出到页面上： ~~~ (function() { var currentSrc, oldSrc, imgEl; var showPicSrc = function() { oldSrc = currentSrc; imgEl = document.getElementById('picimg'); currentSrc = imgEl.currentSrc || imgEl.src; if (typeof oldSrc === 'undefined' || oldSrc !== currentSrc) { document.getElementById('logger').innerHTML = currentSrc; } }; // You may wish to debounce resize if you have performance concerns window.addEventListener('resize', showPicSrc); window.addEventListener('load', showPicSrc); })(window); ~~~ 你可以在[示例页面](http://codepen.io/airen/pen/JYRvOZ)观察实际反映。改变浏览器尺寸来观察`currentsrc`的变化。 将你的浏览器慢慢的缩小，你将看到如下图的一个变化效果：  ## 为什么会这样？ `<img>`总是显示当前资源，这意味着任何与`<img>`元素交互的JavaScript代码都会如期持续工作。 （还没提到几十年来浏览器开发人员写的非常有价值的正确处理图片代码） 正如Eric Portis所说，当我们使用新的响应式图片标准时，“[我们正逐渐加强`img`](http://alistapart.com/article/responsive-images-in-practice)”的特性。 ## 还需要img以外的东西吗？ 在一些场景下单独用`img`可能就够了： * **固定宽度，单一分辨率网页**:如果你没有用响应式设计并且不用担心"retina"屏幕，`img`元素就够了。 * **文件尺寸差别很小**:对于有些图片，最大版本和最小版本的尺寸没有很大区别。常见的有logo，图标和其他不需要根据视窗变化的小图片。如果文件尺寸没什么区别，一张图片可能就够了。 * **使用基于矢量的图片例如[SVG](http://en.wikipedia.org/wiki/Scalable_Vector_Graphics)**:如果使用基于矢量的图片格式例如SVG，图片可以自由缩放并不需要多张图片。在这种情况下，可以直接用SVG做为`img`的图片源。 当然，这取决于需要适配的浏览器是否支持SVG。最好使用`picture`元素来提供可选的图片格式作为备用方案。会在这个系列里将会介绍这个元素的使用。 ## 想要支持高分辨率屏幕怎么办？ 如果想要支持高分屏，我们需要扩展`<img>`元素。请看这个系列的第3部分:**`Srcset`显示分辨率**。

> 译文出处：http://www.w3cplus.com/responsive/responsive-images-101-definitions.html > 英文原文：http://blog.cloudfour.com/responsive-images-101-definitions/ 过去这些年，我们写了[不少关于响应式图片的文章](http://blog.cloudfour.com/?s=responsive+images)。如今既然[响应式图片已经运用](http://blog.cloudfour.com/responsive-images-are-here-now-what/)在浏览器里了，似乎也是时候回顾和总结一些入门指南给那些刚刚开始探索响应式图片的同学。 因此，我们推出一个新系列叫做响应式图片101，在里面我们会谈到为什么需要响应式图片以及如何选择正确的响应式图片解决方案。 让我们深入学习吧！ ## 响应式图片是什么？ 最开始响应式网页设计的关键部分之一就是让浏览器能够自动调节图片尺寸。 然而，仅仅改变图片尺寸意味着用户仍然需要下载体积过大的图片。比如下面这个Apple Watch图片：  这张图片的[大尺寸版本]((http://www.w3cplus.com/sites/default/files/blogs/2015/1509/hero_ygold_edition_large_2x.jpg)，主要用在iMac之类的大尺寸高分屏上，尺寸为**`5144px x 1698px`**。体积是**`398K`**。 把这样一张大尺寸的图片传送到一些设备例如[Blackberry Curve 9310](http://us.blackberry.com/smartphones/blackberry-curve-9310.html)——设备分辨率为`320px x 240px`——没有任何意义。我们需要更小一点的图片。 因此，提及响应式图片时，我对它的具体定义如下： > 根据显示器分辨率，提供多个图片源，在页面上图片的尺寸，或者其它参数的一种方法。 通常，谈到响应式图片，人们倾向于内联图片的解决方案。这是为什么呢？让我们来讨论一下老朋友`<img>`元素： ~~~ <img src="giraffe.jpg" alt="Giraffe"> ~~~ 事实上`<img>`只能提供单一图片源，这一点成了一个巨大的挑战。但是响应式图片技术不仅仅局限在HTML上。我们之后会在这个系列中研究相关的CSS技术。 ## 了解使用情况 当你开始寻找响应式图片解决方案时，最重要的是决定哪个解决方案对现有的情况最有利。找到最佳方案的关键是了解清楚当前要解决的问题。 [响应式图片讨论组](http://responsiveimages.org/)定义了多种[使用情况](http://usecases.responsiveimages.org/)。我建议你去阅读完整的使用情况列表——里面有很多好东西——但是出于说明目的，我将主要说明两种使用情况：分辨率切换和艺术指导。 ### 分辨率切换 分辨率切换是最常见的使用情况。它应用于任何想要提供不同尺寸同时又不想对内容或者图片的宽高比进行任何改动的解决方案。  分辨率切换不仅包括可以根据视口尺寸灵活改变图片尺寸，还包括基于不同显示器分辨率提供不同图片源的脚本（也称为，retina图片）。 ### 艺术指导 每当需要基于页面中图片的尺寸改变一张图片的内容或宽高比时，你就会遇到被RICG称为艺术指导的情况。 我们用下面的[奥巴马总统在克莱斯勒工厂演讲的照片](http://www.flickr.com/photos/barackobamadotcom/5795228030/)作为例子。  当照片以大尺寸显示时，显示出背景里的汽车工厂是有意义的。背景可以在图像上说明这个事件发生的地点。然而试想如果我们把图片缩小来适应小屏幕的时候呢？ 奥巴马在克莱斯勒工厂演讲的照片被缩放到宽度为`100px`。在这个尺寸上奥巴马自己都很袖珍。  在这个尺寸上几乎认不出奥巴马。你无法辨认出他的脸部。因此，我们不应该简单得缩放图片，而应该合理裁切图片去掉一些背景从而把焦点放到奥巴马身上。最终结果这张图片在小尺寸上的表现变得更好。  奥巴马在克莱斯勒工厂演讲的照片被缩放到宽度为`100px`并且被裁切因而显得更好。 艺术指导不仅仅是裁切图片。例如，在Nokia的网页上展示的新一代浏览器，你可以看到图片基于屏幕尺寸改变而从风景变为肖像。 *视频要翻墙浏览。* 正如Stephanie Rieger在[创新开发会议](https://vimeo.com/35352401)上解释的那样，最终他们决定改变图片从而让浏览器自身看起来更舒服。如果图片缩放得太小，浏览器内容变的无法阅读因此才从风景切换为肖像。 我遇到的最常见的艺术指导场景是包含文字的图片。我们看CB2页面上的例子以及一张hero image。  这个图像包含了三个照片，两个带有文字的logo，一个描边邮戳和文本。如果我们只是把这个图像调整到`320px`宽，文本将会变得太小而无法辨认。  CB2目前没有一个响应式的网站，但是他有一个移动网站，我们可以看到他们如何在小屏幕上处理这个图像。  为了使图像在小屏幕上起作用，CB2做了如下操作： * 从三个图片变为两个 * 去除文本 * 改变长宽比使图片更高 * 重新设计图像的布局 如你所见，为了使Hero image在小屏幕上起作用而必须要作出的改变是很多的。 ## 游戏开始 既然我们现在已经对响应式图片有了一个定义，我们可以开始研究这些解决方案的原理。下一节将介绍图片依赖。

本文根据[@Jason Grigsby](http://blog.cloudfour.com/author/jason-grigsby/)的《[Responsive Images 101, Part 1: Definitions](http://blog.cloudfour.com/responsive-images-101-definitions/)》所译，整个译文带有我们自己的理解与思想，如果译得不好或有不对之处还请同行朋友指点。 ## 作者  ### [Blueed](http://weibo.com/blueed) 现居上海。正在学习前端的道路上，欢迎交流。 个人博客：[Blueed.me](http://blueed.me/),微博：[@Ivan_z3](http://weibo.com/blueed)