不是因为web标准的初期，我已经看到了我们身边一个看似很小的问题，社会反弹：响应图像。
在过去的4年 （是的，它已经四年左右），我们在响应式设计看到的图像的各种排列组合。 从设置的懒惰天max-width: 100%绝对最低你应该做的），更全功能的JavaScript实现，如Picturefill和Zurb的data-interchange方法，我们已经花了很多时间转动轮子，撞我们的头和尖叫在墙上。 我很高兴地说，我们不懈的旅程即将结束。 在W3C和浏览器制造商得到了暗示。
响应图像的状态
在我们寻求神圣的右图像服务给用户梦寐以求的目标，我们对浏览器厂商到现在为止的态度在很大程度上是“忘记你 – 我们会做我们自己。”我当然也不例外。 我们是如此细心的敏感图像和暴露给所有的猜测和试验通常不释放我们得不耐烦（理应如此），并用JavaScript做了公众的利益。
一个CSS过渡和一个负责任的图像之间的差异，当然，他们是如何降解 。 如果一个CSS过渡不起作用，谁真正在乎呢？ 你的界面可能会有点神经质，但经验作为一个整体不会真的受到影响，因为你的用户仍然能够完成他们的目标，消耗他们所需要的内容。
这真的是不带有图像的情况。 如何做一个新的形象标签降解？ 在img标记了广泛的认同，我什至无法找到时，W3C推荐它作为一个标准，比在一个小参考其他的HTML 4.01规范 。 更换或什至扩大在img标签会像告诉弗兰克·西纳特拉戴棒球帽，而不是一个Fedora的-你会得到一些推回。
资源问题
作为响应式设计逐渐普及和通过它用户消费信息的媒体变得无法控制，我们慢慢意识到， img本身是不会削减芥末。 我们开始问这样的，“什么屏幕尺寸的用户？”和“什么是屏幕的像素密度？”这些问题刺激我们的图像技术，直到我们意识到，屏幕尺寸和像素密度都绝对给量没有关系的问题可用带宽来提供一个巨大的高清晰度图像。
该解决方案得到了相当复杂的。 在通话picture元素开始，和一组名为响应图像社区组（RICG）出现了。 该RICG开始工作的有关picture元素，与沿途的W3C共享工作。 其结果使我们今天所有的公司已经取得的进展的讨论。
的介绍srcset
因为大多数敏感图像社区在船上与picture元素期待着它的伟大polyfills，如Picturefill因为和，它说干就干，并且放出了深思熟虑和充实的文件，概述了一种叫srcset ，这是标准的一个扩展img标记。 是的，我知道 – 这感觉就像是从哪儿冒出来。 这也是超级复杂和过于限制通过限制你（暗示）的像素值，并使用microsyntax未允许的可扩展性，在未来的媒体查询。 幸运的是，语法已发展成为我们所拥有的今天，这是一个相当强大的建议。
最近，安德鲁·克拉克说，最好的时候，他啾啾 ，“看着响应图像srcset和尺寸第一次属性。 啊呀它是复杂的。“
我不能说这更好的自己。 让我们来看看什么是我们正在处理：
<img alt="dog" src="dog.jpg" srcset="dog-HD.jpg 2x, dog-narrow.jpg 300w, dog-narrow-HD.jpg 600w 2x">
三大属性在上面的代码片段： alt ， src和srcset 。 的alt属性是相同的，因为它一直是， src是回退，如果srcset不支持; 和srcset显然是香饽饽这里。
我们可以看到三个参数srcset 。 首先是该图像的路径。 第二提供有关来源的自然宽度的浏览器信息，以便它知道要提供的资源给用户（根据用户的喜好和交叉引用与该sizes属性 -我告诉你这是复杂的）。 最后一块设置可选的像素比（ 2x在这个例子中指定了高清图像）。
有一件事我真的很喜欢约srcset是，该规范指出，浏览器应包含一定的带宽情况下的图像分配偏好。 这意味着你不必担心服2x的图像的高清晰度屏幕，如果该设备是在眉头3G连接。 用户的喜好应该接管，并且浏览器会选择适当的图像服务。
准备picture元素
经过一番抱怨我们的新怪的朋友， srcset的RICG继续工作的有关picture元素，它终于得到与浏览器厂商一些严重的牵引……嗯，就是用Chrome浏览器。 建议语法picture元素可能看起来很熟悉，因为我们看到它主要是在Picturefill的第一个版本，它是没有什么不同怎么<audio>和<video>标记了。
<picture> <source media="(min-width: 600px)" srcset="large-1.jpg, large-2.jpg 2x"> <img alt="A fat dog" src="small-1.jpg"> </picture>
正如你所看到的， source标签的picture元素，以及一个正常的img标记。 正如我们看到的src在srcset ，在img是一个备用的。 在source标签，我们有什么看起来像一个媒体查询，旁边一个srcset包含像以前相同的图像源和像素密度的参数属性。 这似乎是一个很好的清洁方式普及响应图像; 我们通常熟悉的语法，所以它应该很容易通过。
浏览器支持
该srcset属性已经在Chrome中支持从版本34。在写作的时候，它不支持任何其他地方。 Mozilla的似乎是工作的一个实现（手指交叉）。 Internet Explorer是遥遥无期。
的picture元素有更糟糕的支持; 它甚至没有在Chrome呢。 但如Mozilla与srcset ，谷歌目前正致力于实现它。 如果你可以忍受通过规范读书，我强烈推荐它。 虽然没有太多的情节和人物的发展是相当弱，它仍然是一个相当不错的读取。
Picturefill 2.0的形成是因为原生的支持是相当接近 。 你知道我们需要一个坚如磐石的polyfill时要使用的时候正式问世，让我们来看一看吧！
介绍Picturefill 2.0
Picturefill 2.0最近发布了测试版，这是从版本1相当大的跳跃。的RICG真正的目的是创建响应图像的一站式解决方案 。 面临的挑战是创建一个脚本，可以让你的开发人员，使用目前正在标准化的解决方案的任意组合，没有它，腹胀到不使用它在所有会比较轻巧的地步。
试想polyfilling，通常会需要2秒使用需要10秒才能加载一个JavaScript文件来加载图像 – 这将没有多大意义。 Picturefill 2.0的规格非常密切关注（有一些故意疏失，我们就去了一个位），让您使用避免了这种srcset或picture ，或两者的组合。
虽然我们不能可靠地实现一切都在使用JavaScript（如合理的检测带宽，这将是一个用户无论如何设置）的规格，我们当然可以照顾所有的，目的是要在HTML中的碎片（即元素和属性）。 这个版本Picturefill的得到我们更接近了一步不需要Picturefill，这是谁曾经写过polyfill人的终极目标。
如果您目前正在使用1.0版，我强烈建议升级到2.0。 这是朝着正确的图像服务给用户一个更好的解决方案迈出了一大步。 一些大的变化已作出的语法和功能。 让我们来看看有什么新的。
有什么新的2.0
有一件事使这个polyfill不同于别人，我所看到的是它polyfills一个概念，而不是HTML的只是一个不支持的块。 Picturefill 1.0使用跨度和自定义属性来模仿我们怎么想的响应图像应该工作。 根据记录，这是一个很好的解决方案，而我目前使用它的很多我还没有被转换成2.0的项目。
在过去一年左右的时间，在规范srcset和picture已经成熟了那么多，所以我们现在可以真正得到使用的东西接近真实的语法。 Picturefill开始看起来像一个真正的polyfill，一是我们可以剥去时，真正的支持显示了。
安装和使用Polyfill
如果你已经读到这里，那么你可能已经处理了过去的一些形式polyfill的。 这个人是没有太大的不同。 Polyfills都应该是设置它和忘记它（从偷线龙科 ），但由于这是一个HTML polyfill，您将需要创建picture元素手动或使用某种形式的HTML下脚来为你做它。 幸运的是，HTML shivs是相当常见的，附带的工具包，如Modernizr的 ; 只是确认picture中支持任何毒刃您选择。
<!-- Create the actual picture element if you haven't already. --> <script> document.createElement( "picture" ); </script>
<!-- Asynchronously load the polyfill. --> <script src="picturefill.js" async></script>
除了 创建的picture元素，你只需要链接到脚本。 使用async属性还建议，使Picturefill不加载挡住你的页面。
使用Picturefill 2.0随着srcset
让我们来看看它提供了最好的支持和使用的语法srcset 。 它应该看起来很熟悉，因为它有我们看到讨论规范时相同的属性。
<img sizes="100vw, (min-width: 40em) 80vw" srcset="pic-small.png 400w, pic-medium.png 800w, pic-large.png 1200w" alt="Obama">
这个片段与规范之间最明显的区别是没有后备的src属性，这是故意除去，以防止影像在不支持的浏览器下载两次。 而且，说真的，这将是这点，如果图像被下载了两次？ 除此之外，这是很忠实的规范，但它可能会随着时间的推移作为规范fleshes出来的polyfill成熟。
在sizes属性告诉图像大小的浏览器相对于视口。 这往往被忽视，因为srcset是流行语了，但这个属性是非常重要的。 如果您想了解更多， 埃里克·波蒂斯使得很多的感觉这个“啊呀繁乱。”
使用Picturefill 2.0随着picture元素
该RICG做这样与Picturefill的第二个版本中做好的语法picture元素应该是毫不奇怪。 它的规格非常接近匹配：
<picture> <source srcset="extralarge.jpg, extralarge.jpg 2x" media="(min-width: 1000px)">
<source srcset="large.jpg, large.jpg 2x" media="(min-width: 800px)">
<source srcset="medium.jpg"> <img srcset="medium.jpg" alt="Cambodia Map"> </picture>
版本1.0和2.0之间的最大的变化是取消了一些传统的HTML（div和跨度），并加入新的元素（的picture和source ）。 此外， srcset支持是内置的（哎呀，为什么不呢，对不对？这是在规范！）。 这是伟大的进步为这个polyfill。
使用尽可能多或尽可能少的这些选项，只要你愿意。 符合规范的行，如果你不希望使用2x选项，你不必（依此类推）。 这与官方之间的差别picture元素是img的回退 。 你会注意到这里说的img后援也有srcset属性，而不是一个正常的， src （这是广泛支持的）。 再次，这是为了避免重复下载（这是一个真正的问题）。 该srcset在img标签也将导致双下载如果浏览器支持srcset但不是picture 。 这个错误应该得到的测试版本制定。
像许多好的polyfills，Picturefill 2.0可以通过编程方式暴露一个全局函数执行， picturefill() 这使您可以使用它在你想要的任何超髋JavaScript框架。 你可以阅读有关的几个选项，针对特定的图像API文档中 。
优雅地退化
在本文的前面，我提到降解的挑战img摆好标签不支持的浏览器。 这是在创造Picturefill 2.0另一个问题。 因为它是一个polyfill，不支持的浏览器的概念是不存在的（那种） – 我们使用JavaScript来迫使它的工作。
边缘的情况是这样的：如果浏览器本身不支持picture或srcset 并已关闭JavaScript，那么你会得到一个frowny脸。 我已经可以感觉到你的眼睛睁不开，但知道依靠它大规模之前，你的系统的局限性是很重要的。 如果用户要遇到一个Picturefill’ed图像中不支持的浏览器关闭JavaScript，他们会看到图像的alt文本-一个可爱的小方法来加强对描述性的和有意义的重要性alt文本，是不是？
替代文字是回退，因为以前<noscript>解决造成问题，支持浏览器picture或srcset但已经禁用了JavaScript（两个图像会呈现）。 该小组还探讨增加一个src属性img （如说明书中），但是，结果在双下载，这违背了相应的图像资源分配给用户的目的。
我们已经走过了漫长的道路与响应的图像。 我们可以看到，光在隧道的尽头，但很多工作仍然有许多工作要做。 我们期待您的帮助！
近期评论