响应式图像_响应式图像：终极指南

响应式图像

Chances are that any Web designers using our Ghostlab browser testing app, which allows seamless testing across all devices simultaneously, will have worked with responsive design in some shape or form. And as today's websites and devices become ever more varied, a plethora of responsive images techniques are appearing to serve developers' needs.

任何使用我们的Ghostlab浏览器测试应用程序(允许同时在所有设备上进行无缝测试)的Web设计人员，都可能会以某种形状或形式进行响应式设计。 并且，随着当今网站和设备的日趋多样化，大量的响应式图像技术似乎可以满足开发人员的需求。

However, responsive design can seem like a minefield. The sheer range of responsive image options on the Web is daunting - and that's before you get into facing the obstacles specific to the site you're working on. But have no fear! Below is a basic outline of what responsive images are, how they can affect your work process, and some of the key defining factors that we think should apply to any designer's thinking, whichever route you choose...

但是，响应式设计似乎是个雷区。 Web上大量的响应式图像选项令人生畏-而这是在您面对正在处理的网站的特定障碍之前。 但是不要害怕！ 以下是什么是响应式图像，它们如何影响您的工作流程以及我们认为应适用于任何设计师的思维的一些关键定义因素的基本概述，无论您选择哪种路线...

什么是响应式图像？ (What Are Responsive Images?)

Put simply, responsive design is an approach that enables your website to fluidly adjust within the parameters of any device - involving a minimum of scrolling or zooming. In other words, creating great-looking sites which are dynamic and flexible enough to be visually responsive to any screen, from mobile widths right up to desktop format. And to make that possible, you of course need a flexible approach to images. Simple, right?

简而言之，响应式设计是一种使您的网站能够在任何设备的参数内进行灵活调整的方法-只需最少的滚动或缩放即可。 换句话说，创建美观，动态和灵活的站点，足以从移动宽度到桌面格式对任何屏幕进行视觉响应。 为了使之成为可能，您当然需要一种灵活的图像处理方法。 简单吧？

Well ... yes and no. While responsive images are now widely used and fairly easy to use in basic layouts, anyone designing more complicated sites will know that issues can quickly rear their ugly heads. Needless to say there is no one key to fit all locks - so we've listed seven of the most common problems below, along with a basic run-through of effective techniques related to each problem, to help you get your site running smoothly.

好吧...是和不是。 尽管响应式图像现在已被广泛使用，并且在基本布局中相当容易使用，但是设计更复杂站点的任何人都将知道，问题会很快抬起他们的丑陋头脑。 不用说，没有一个适合所有锁的钥匙-因此，我们在下面列出了七个最常见的问题，以及与每个问题相关的有效技术的基本介绍，以帮助您使网站平稳运行。

有什么问题？ (What Are The Problems?)

One major factor in the need for responsive images is overall website size - even today, a huge percentage of mobile-version sites are as large (or even larger) than their desktop versions, thereby affecting performance negatively. Images play a large part in this, as image quality and size in general continues to increase, but it makes little sense if the data is wasted by mobile devices or desktops with low bandwidth connection. So to improve efficiency, more designers now using responsive images - however, these often open up their own cans of worms.

要求响应式图像的一个主要因素是网站的总体规模-直到今天，很大一部分的移动版网站都比其桌面版大(甚至更大)，从而对性能造成负面影响。 图像在其中起着很大的作用，因为图像的质量和大小通常会不断增加，但是如果数据被低带宽连接的移动设备或台式机浪费掉了，那意义不大。 为了提高效率，现在有更多的设计师使用响应式图像-但是，这些图像通常会打开自己的蠕虫罐。

Scaling images down to better fit devices is the most common approach to making content responsive, but in many cases this can make the image less powerful - the ‘art-direction problem'. Other less aesthetic issues, such as processes which either don't ‘validate' or aren't considered strictly semantic, can for some designers (or clients) be a stumbling block. Then there are the technical aspects to consider - server-side components, use of JavaScript, bandwidth testing, and third-party options. All these issues have (more or less) great solutions, so read on to discover which suits you best.

缩小图像以使其更适合设备是使内容具有响应性的最常见方法，但是在许多情况下，这会使图像的功能减弱-“艺术方向问题”。 对于某些设计师(或客户)来说，其他一些不太美观的问题(例如未“验证”或未严格视为语义的过程)可能是绊脚石。 然后是要考虑的技术方面-服务器端组件，JavaScript的使用，带宽测试和第三方选项。 所有这些问题(或多或少)都有很好的解决方案，因此请继续阅读以找出最适合您的问题。

问题1-语义 (Problem 1 - Semantics)

Making responsive images work cleanly and reliably across multiple platforms sometimes involves using techniques that aren't ‘semantic'. Why? Because when the src of an image points to a real image, with an alt text to describe it, even if the src is the smallest image possible, it means you're downloading unnecessary data.

要使响应式图像在多个平台上干净可靠地工作，有时会涉及使用非“语义”技术。 为什么？ 因为当图像的src指向实际图像时，用alt文字来描述它，即使src是可能的最小图像，也意味着您正在下载不必要的数据。

To get around this, some of the techniques described below require the src of the image to be removed, or to link to a transparent GIF for example. If this doesn't suit and you're looking for a semantic approach, then Adaptive Images by Matt Wilcox, or the HiSRC jQuery plugin by Marc Grabanski and Christopher Schmitt, are two excellent options to look at.

为了解决这个问题，下面描述的某些技术要求删除图像的src，或者例如链接到透明GIF。 如果这不合适，并且您正在寻找一种语义方法，那么Matt Wilcox的Adaptive Images或Marc Grabanski和Christopher Schmitt的HiSRC jQuery插件是两个不错的选择。

自适应图像 (Adaptive Images)

If the site you are working on has a large amount of legacy images, it may not be workable to go through and adjust every image with special markup or specialised CSS. In this case, Adaptive Images is arguably the best solution out there. It requires no custom markup for any images and thus enables backwards compatibility by resizing images automatically. However, it does require the Apache 2 Web server and PHP 5.x, which may not be compatible with your site's platform (more on this later). It also requires that your images be hosted with your Web server, as opposed to elsewhere via a delivery network.

如果您正在处理的站点上有大量的旧图像，则可能无法使用特殊的标记或特殊CSS浏览并调整每个图像。 在这种情况下，自适应图像无疑是最好的解决方案。 它不需要任何图像的自定义标记，因此可以通过自动调整图像大小来实现向后兼容。 但是，它确实需要Apache 2 Web服务器和PHP 5.x，它们可能与您的站点的平台不兼容(稍后将对此进行详细介绍)。 还需要将图像托管在Web服务器上，而不是通过传送网络在其他位置托管。

高铁 (HiSRC)

Unlike Adaptive Images, HiSRC does require custom markup in the HTML, and so may not be appropriate in the case of sites with high legacy content. On the other hand, it gives you the freedom to specify custom cropping or zooming of images for smaller platforms (the ‘art-direction problem' discussed below), as well as enabling the script to pick different image resolutions according to network speed (‘the bandwidth problem') - neither of which Adaptive Images does. On the downside, HiSRC will only work if you're using the jQuery library, so if that's not an option try one of these other solutions.

与Adaptive Images不同，HiSRC确实需要HTML中的自定义标记，因此对于具有大量旧内容的网站可能不合适。 另一方面，它使您可以自由地为较小的平台指定图像的自定义裁剪或缩放比例(如下所述的“艺术方向问题”)，并允许脚本根据网络速度选择不同的图像分辨率(带宽问题”)-自适应图像都没有。 不利的一面是，HiSRC仅在您使用jQuery库时才有效，因此，如果不行，请尝试以下其他解决方案之一。

问题2-艺术指导 (Problem 2 - Art Direction)

A picture tells a thousand words ... most of the time. Many responsive image techniques enable you to provide several resolution versions of an image, which can then be used accordingly for suit a given platform. However, this can sometimes have a negative effect where the message of the image is diluted or lost altogether. What's the minimum size for an image? The answer, of course, depends on context.

图片在大多数时候告诉一千个单词。 许多响应式图像技术使您能够提供图像的多个分辨率版本，然后可以将其相应地用于特定平台。 但是，在图像的信息被稀释或完全丢失的情况下，这有时会产生负面影响。 图片的最小尺寸是多少？ 答案当然取决于上下文。

Even the most stunning images can lose their power when scaled down to fit the confines of smaller devices such as mobiles. If this predicament applies to your site, you'll need a solution that addresses the ‘art-direction problem' by enabling custom cropping and zooming specifications. Both the HiSRC and Picturefill techniques (described below) offer lots of flexibility here, but remember - if your site has a high number of legacy images, you'll be doing a lot of custom markup, which perhaps isn't desirable.

按比例缩小以适应较小的设备(例如手机)时，即使是最出色的图像也可能会失去其功能。 如果这种情况适用于您的网站，您将需要通过启用自定义裁剪和缩放规格来解决“艺术方向问题”的解决方案。 HiSRC和Picturefill技术(如下所述)在此都提供了很大的灵活性，但是请记住-如果您的站点具有大量的旧图像，您将进行大量的自定义标记，这也许是不希望的。

问题3-有效性 (Problem 3 - Validity)

If you are customising markup, checking markup validity using a validation service such as W3C ensures that a construct follows the correct syntax of whatever language it works with (for example, HTML). While most of the time browsers are able to think ahead to present Web pages that aren't strictly ‘valid' without any problems, these results can sometimes vary between one browser and another. In rare cases, it can cause confused layouts or even crashes. ‘Validating' every page is a bulletproof way of identifying these problems before they occur.

如果您要自定义标记，请使用W3C之类的验证服务检查标记的有效性，以确保构造遵循其所使用的任何语言(例如HTML)的正确语法。 尽管大多数时候浏览器都能够考虑到呈现严格意义上并非“有效”的网页，但是在某些浏览器之间，这些结果有时会有所不同。 在极少数情况下，它可能会导致布局混乱甚至崩溃。 “验证”每个页面是在这些问题发生之前进行识别的防弹方法。

But that's not to say invalid code can't work seamlessly across all browsers! In fact it often does. Picturefill by Scott Jehl is loved by many and uses JavaScript for the <picture> element to display responsive images, and it works excellently in spite of being technically invalid syntax. Go ahead with whatever works best for you: if validity is a must, then Adaptive Images or HiSRC may be a better fit.

但这并不是说无效代码无法在所有浏览器中无缝运行！ 实际上，它经常这样做。 Scott Jehl编写的Picturefill被许多人所喜爱，并且在<picture>元素中使用JavaScript来显示响应图像，尽管它在技术上是无效的语法，但它仍表现出色。 继续进行最适合您的工作：如果必须确保有效性，那么“自适应映像”或HiSRC可能更合适。

问题4-带宽能力 (Problem 4 - Bandwidth Capabilities)

Much as we'd all like to say otherwise, a world of super-speed connections and lighting-fast load times for everyone is still some way off. That's why in many developers' opinions, responsive images ought to consider the bandwidth available on any given device, and adjust the image size accordingly to cut out excess downloads.

就像我们所有人都想说的那样，对于每个人来说，超高速连接和照明快速加载时间的世界还有一段距离。 这就是为什么在许多开发人员看来，响应式映像应该考虑任何给定设备上可用的带宽，并相应地调整映像大小以减少过多的下载。

Foresight.js by Adam Bradley is a solution that works as a kind of connection speed checker, by first downloading a 50K test file and then determining which size image suits best: a technique that is also available with HiSRC. The downside of this? The test image means an additional 50K download, and a potentially delayed page load time. However, many consider this preferable to serving up large images that go unused.

Adam Bradley的Foresight.js是一种解决方案，它可以用作一种连接速度检查器，方法是先下载50K测试文件，然后确定最适合的尺寸图像：HiSRC也提供了这种技术。 不利之处？ 测试映像意味着需要额外下载50K，并且可能会延迟页面加载时间。 但是，许多人认为这比提供未使用的大图像更好。

问题5-服务器端组件 (Problem 5 - Server Side Components)

The bulk of Adaptive Images' work is done through .htaccess and PHP 5.x, which offers a great solution without complete dependency on JavaScript. The problem with .htaccess is that it assumes your website is running on an Apache server. If you're using something else, such as Nginx, you can port the .htaccess over to Nginx syntax - which is similar to Apache's but this still involves some work. Additionally, adding PHP files to your site's root directory may not be possible if you're running on other technologies, such as Ruby or Python. Clearly this isn't ideal for everyone, so be sure to check first before you dive in.

自适应图像的大部分工作是通过.htaccess和PHP 5.x完成的，它们提供了一个很好的解决方案，而无需完全依赖JavaScript。 .htaccess的问题在于，它假设您的网站正在Apache服务器上运行。 如果您使用的是Nginx等其他内容，则可以将.htaccess移植到Nginx语法上-与Apache的语法类似，但这仍然涉及一些工作。 此外，如果您在其他技术(例如Ruby或Python)上运行，则无法将PHP文件添加到网站的根目录中。 显然这并不适合所有人，因此请务必在潜水之前先进行检查。

问题6-JavaScript (Problem 6 - JavaScript)

As you've probably noticed, many of the responsive image techniques above require some JavaScript. If you'd prefer to keep things as simple as possible and want to avoid using JavaScript altogether, then take a look at the third-party Sencha.io Src solution discussed a little further down.

您可能已经注意到，上面的许多响应式图像技术都需要一些JavaScript。 如果您希望使事情尽可能简单，并且不想完全使用JavaScript，那么请看一下进一步讨论的第三方Sencha.io Src解决方案。

JavaScript applies to most of the options listed here. Some only use a tiny bit, while others involve quite a lot of configuration depending on the scale of your project. Even the Adaptive Images technique requires JavaScript, although only a very minimal amount, doing most of its magic through Apache and PHP. Which leads us on to ...

JavaScript适用于此处列出的大多数选项。 有些只用了一点点，而有些则根据项目的规模而涉及大量的配置。 即使是自适应图像技术，也需要JavaScript(尽管只有很少的一部分)才能通过Apache和PHP来完成其大部分工作。 这导致我们继续...

问题7-第三方 (Problem 7 - Third Parties)

If you prefer to outsource, Sencha.io Src is a completely third-party technique for resizing images to fit any given user. By acting as a proxy for images, it ensures you need never delve into custom configurations on your server - just point the image to Sencha.io, which then uses its user-agent string to detect the parameters of the device, and your image is resized!

如果您愿意外包，Sencha.io Src是一种完全第三方的技术，用于调整图像大小以适合任何给定的用户。 通过充当图像的代理，它可以确保您无需研究服务器上的自定义配置-只需将图像指向Sencha.io，Sencha.io就会使用其用户代理字符串来检测设备的参数，并且您的图像就是调整大小！

There are several other options if you're taking the third-party route. An alternative to Sencha.io is ReSRT.it, which offers a very similar service but without user-agent detection or cookies. It also allows for bandwidth detection and flexibility to address the art-direction problem, if that applies to your site. Device Atlas Cloud, Responsive.io, and Thumber.io are other options, just to name a few.

如果您选择第三方路线，则还有其他几种选择。 替代Sencha.io的是ReSRT.it，它提供了非常相似的服务，但没有用户代理检测或cookie。 它还适用于带宽检测和灵活性，以解决艺术指导问题(如果适用于您的站点)。 Device Atlas Cloud，Responsive.io和Thumber.io是其他选项，仅举几例。

Needless to say, third-party dependency is to be treated with caution. While these solutions often work perfectly and are convenient (and free for individual users, in the case of Sencha.io) you always run the risk of unexpected downtime. So it's best to weigh up the potential consequences before you jump in!

毋庸置疑，对第三方的依赖关系应谨慎对待。 虽然这些解决方案通常可以很好地工作并且很方便(对于Sencha.io，这对于单个用户是免费的)，但是您始终会冒意外停机的风险。 因此，最好在加入之前权衡一下潜在的后果！

今日最佳实践 (Best Practice Today)

Picturefill 2.0 was recently released as beta, and it's quite a large jump from version 1.

Picturefill 2.0最近以beta版本发布，与版本1相比有很大的提高。

It allows us to use responsive images now and in a way that start to take care of some of the issues discussed above.

它使我们现在可以使用自适应图像，并且可以开始处理上面讨论的一些问题。

安装和使用Polyfill (Installing and using a polyfill)

Polyfills are meant to be set-it-and-forget-it, but because this is an HTML polyfill, you'll either need to make the picture element manually or use some form of HTML shiv to do it for you.

Polyfills是要设置并忘记的，但是由于这是HTML polyfill，因此您需要手动制作picture元素或使用某种形式HTML shiv为您完成。

HTML shivs are pretty ubiquitous and come with toolkits such as Modernizr; just verify that picture is supported in whatever shiv you choose.

HTML shivs非常普遍，并且带有诸如Modernizr之类的工具包； 只需验证所选图片是否支持该图片即可。

<!-- 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>

Apart from creating the picture element, you have to link to the script. Using the async attribute is also recommended, so that Picturefill does not stop your page from loading.

除了创建图片元素之外，您还必须链接到脚本。 还建议使用async属性，以便Picturefill不会阻止页面加载。

将PictureFill 2与srcset一起srcset (Using PictureFill 2 with srcset)

Ok so now we'll look at the syntax that provides the best support and that uses srcset.

好的，现在我们来看看提供最佳支持并使用srcset的语法。

It should look familiar because it has the same attributes that we saw when discussing the specification.

它应该看起来很熟悉，因为它具有与讨论规范时所看到的相同的属性。

<img sizes="(min-width: 40em) 80vw, 100vw” 
srcset="pic-small.png 400w, pic-medium.png 800w, pic-large.png 1200w" alt="Obama”>

The main difference between this snippet and the specification is the removal of a fallback src attribute, which was intentionally taken out to prevent images from being downloaded twice in unsupported browsers.

此代码段与规范之间的主要区别在于删除了备用src属性，该属性是有意删除的，以防止在不受支持的浏览器中两次下载图片。

The sizes attribute tells the browser of the image's size relative to the viewport. This often gets overlooked because srcset is the cool kids choice now, but this attribute is equally important.

Sizes属性告诉浏览器图像相对于视口的大小。 由于srcset现在是孩子们最酷的选择，所以这常常被忽略，但是此属性同样重要。

将PictureFill 2与picture元素一起使用 (Using PictureFill 2 with the picture element)

The RICG did such a good job with this second version of Picturefill that the syntax of thepicture element should come as no surprise. It matches the specification very closely:

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>

The biggest change between versions 1.0 and 2.0 is the removal of some traditional HTML (divs and spans) and the addition of newer elements (picture and source). Also, srcset support is built in.

1.0版和2.0版之间最大的变化是删除了一些传统HTML(div和span)并添加了更新的元素(图片和源代码)。 此外，还内置了srcset支持。

The difference between this and the official picture element is the img fallback. You'll notice here that the img fallback also has asrcset attribute, instead of a normal src (which is widely supported).

此图片与官方图片元素之间的区别是img后备广告。 您会在此处注意到，img后备也具有asrcset属性，而不是普通的src(已得到广泛支持)。

Again, this is to prevent double-downloading. The srcset in the img tag would also cause double-downloading if the browser supports srcset but not picture.

同样，这是为了防止重复下载。 如果浏览器支持srcset但不支持图片，则img标记中的srcset也将导致重复下载。

结论 (Conclusion)

It goes without saying that until a magical one-for-all formula comes along, none of the solutions above will address every possible design eventuality. But that doesn't mean you can't create beautiful, responsive content that works like a dream from desktop to mobile. As with most things, the key is to weigh up which problems you most want to solve - be they legacy content, bandwidth, art direction or others - and start from there. Good luck, and as ever we'd love to hear your thoughts and stories about how you're getting on with responsive images, and with Ghostlab.

不言而喻，直到出现了神奇的万能公式，以上解决方案都无法解决所有可能的设计可能性。 但这并不意味着您无法创建美观，响应Swift的内容，从台式机到移动设备都像梦一样。 与大多数事情一样，关键是权衡您最想解决的问题(无论是遗留内容，带宽，美术指导还是其他问题)，然后从那里开始。 祝您好运，我们将一如既往地希望听听您关于如何使用响应式图像和Ghostlab进行交流的想法和故事。

翻译自: https://davidwalsh.name/responsive-images

响应式图像