What means to provide responsive images should you use?

Recently, a whole bunch of ways to create responsive images ( responsive images ) have appeared - in other words, technical tools have appeared that ensure the substitution of correct illustrations depending on a number of conditions (for example, screen size and Internet access speed of the reader). All of these tools do their job a little differently; To compare them, Christopher Schmitt and I compiled a spreadsheet of their capabilities and requirements.

The table shows the information, but for their assimilation, let's think about it through practical issues.

When choosing the method that is suitable for you and for your project, these questions can serve as a hint. Many of these questions may relate to your project, so you will have to evaluate which techniques are better in what circumstances and then summarize this understanding.
')

How much old content do I have?

In fact, this question means “do I have such old content that will not be updated?”. For example, on the CSS Tricks site I have over a thousand pages, and I work on them alone:

[former content statistics]

Yeah ... I’m not going to go back and fix every <img> element on this site, so I’ll need a method to leave them alone.

The only tool I know that doesn’t require changes to the markup to work at all is Adaptive Images . It works by redirecting requests to images through a PHP script that intelligently selects (and, if necessary, creates) illustrations of the size that fits the width of the screen from the reader.

You should also ask yourself about how old content you care about. Perhaps the vast majority of visitors to your site are interested only in new content, in the markup of which you can make the necessary changes for the use of any technical means you like. If so, read on, you will learn about them.

If you have a small website, or a new website, or if it is not difficult for you to return to the previous content and update it, then you can also choose a tool that requires special markup; then again read on.

Is special markup appropriate for me?

This is a sub-question of the previous question. Many means of providing responsive images will require you to use a special HTML code. For example, for HiSRC, you will need to place the addresses of high-resolution images in the data attributes:

<img src="200x100.png" data-1x="400x200.png" data-2x="800x400.png">

This technique creates a clear, valid, semantically correct code, but it also makes it necessary to add these attributes to each <img> element on the site, which may not be possible for sites with heaps of previous content.

If you come to the idea that a special markup (or a specialized CSS style) is not suitable for you, then only Adaptive Images remains. After all, even for Sencha.IO you will need to place the prefix in the src attribute, and this will require processing of the previous content.

Do I need semantic code?

Some techniques of creating responsive images imply a markup that is not semantic in the strict sense. After all, there is only one way to be semantic for an image: its src attribute should point to a real image, and the alt attribute should contain text describing that image. What Brad Frost summed up well:

In other words, if the tech- nical technique may require that the src attribute of the image is missing, or refer to a transparent GIF, or something of the same kind, then the code will not be semantic.

Well, why do some tools for creating responsive images resort to this? Yes, because if the illustration attribute src points to a picture with a horse, then this picture will start downloading immediately after the browser reads the illustration code. There is no practical way to prevent this. Even if you super- replace this src with a more suitable version of the image, then the browser will download two pictures instead of one - it will not be a gain, but a loss in speed. You may, however, find it acceptable (for example, for desktops, usually, the Internet connection speed is higher than that of mobile phones). Usually, if such a technique is used, then in src indicate the smallest of the pictures of different sizes.

If semantics is important to you, then take a look at the aforementioned Adaptive Images or at HiSRC , a jQuery plugin created by Christopher Schmitt and allowing use with the src semantic attribute.

Some other tools use the <noscript> element , in which the <img> reinsurance code is placed in case JavaScript is disabled or not available. I leave it to you to decide whether this is semantic code or not.

Do I need a valid code?

By validity is here meant the ability of a code to pass the W3C Markup Validation Service . This verification tool helps you find the problem code, helps to create markup better. But the code does not get worse simply because it does not pass the test: if the invalid code works fine in all browsers, then its validity should not concern you or anyone else.

However, if you need validity (for example, if the customer necessarily requires it from you, threatening to refuse to pay for the work), you cannot use some means of providing responsive images. For example, picturefill uses the <picture> element, which may eventually be standardized, but this is not the case now, so the code is invalid. In addition, the standard requires that the <img> element has an src attribute - so that abandoning this attribute with the intention of avoiding the above-mentioned problem of double image request also results in invalid code.

If the validity of the code is an indispensable requirement for you, then I recommend Adaptive Images , or HiSRC , or Responsive Enhance . All of these tools use the simple and valid <img> syntax, which contains the src attribute.

Do I need subtle control over the images?

Some means of providing responsive images give the reader proportionally reduced versions of the same large picture. Although it makes life easier (less has to be done), the result may be unacceptable. Here is a good example of a better approach:

[three illustrations]

The left of these three pictures is intended for mobile phones and is initially indicated in src . Medium, somewhat larger, can be used by tablets. On the right - the largest of the illustrations. ( Here is their source .)

These images are the result of the handwork of a designer who used clipping to preserve the meaning and impression of the photo. If, instead, to take the right picture and simply subject to proportional reduction, then the people depicted in the photo will be very small, the impression of the illustration may be lost.

If the concept of fine control over images is important for your project, then you need a tool that will allow you to specify exactly what src is used in what circumstances. Ideal picturefill , allowing with sufficient accuracy to specify the addresses of pictures and the circumstances of their use:

 <picture alt="description"> <source src="small.jpg"> <source src="medium.jpg" media="(min-width: 400px)"> <source src="large.jpg" media="(min-width: 800px)"> </picture>

Next they do javascript.

Do I need JavaScript?

Most of the tools for creating pictures of pictures, it is with javascript that does its tricks. Some of them are very few (just to set a cookie), but still javascript. For several tools, you will have to put <img> inside the <noscript> element in case that JavaScript is disabled in the reader. If you do not like this approach, but if you also need to be sure that the pictures will work without javascript, then you should rely on Sencha.IO . This service is based on the identification of the device by the header "User-Agent" and transmits a correspondingly reduced image. So you refer to the largest (reasonably) version of the image you have, and Sencha will reduce it and give the reader a smaller version if necessary (however, for obvious reasons, it does not increase the number).

How about dependence on javascript libraries?

Both HiSRC and rwdImages work on jQuery. If your project uses another library, then these tools may not be suitable for you. (But you can port them and then open the source code!) And if you do not use any library, well, then it would be time, probably, but now we will not talk about it.

Do I need server scripts?

Some of the tools we are discussing depend not only on javascripts. Adaptive Images relies heavily on .htaccess and PHP. Well, .htaccess assumes Apache server. And although, of course, we all know and love PHP (khe-ghm), many websites work on technologies like Ruby or Python.

Responsive Images (the original version of the Filament Group) also uses .htaccess. So if, as a server, you have something like Nginx , then you will have to either refuse this technical tool or port the .htaccess code to a similar, but different Nginx configuration syntax.

Do I need to check the speed of the Internet with the reader?

Finding out the width of the browser window and deciding on which picture to deliver to the reader is fine, and this is the basis of the very idea of responsive pictures. However, in fact, this should be only half of the reasons for such a decision. The other half is the speed of communication with the Internet. If the reader has a fairly fast connection to the Internet, then transferring large illustrations to it is normal. If the reader has a very slow connection to the Internet, then it should receive smaller images (regardless of the width of the screen). What a pity that Internet speed media queries are not implemented in the browsers themselves.

Two current image responsiveness tools check the speed of the Internet when they make decisions: Foresight.js and HiSRC (they use the same trick from Foresight.js). This works by downloading a test file with the measurement of download time (the threshold value is configured in the configuration). The test itself slows down the loading of the page, but, theoretically, saving on the size of images downloaded depending on the speed is worth it.

Can I rely on the services of others?

Sencha.IO is a fully external service providing responsive images. As far as I know, it works perfectly, there are no major interruptions in her work, but, of course, there is always a risk.

Of course, you can think like this: “Cool, the Sencha.IO techniques are excellent, but the need to rely on their server is disturbing — I would like to run something like this on my server.” If you really want this, then there is a publicly available WURFL database , and there is a Server Side Responsive Images tool for working locally with it.

There are also services like Device Atlas Cloud that deal with device recognition. They also create self dependence. There is no doubt: their goal is to stay online all the time and work quickly, but be careful about how and from whom you want to depend on your business.

Is there a special CMS with special features?

Suppose your project is based on WordPress. And in WordPress there is in fact a built-in illustration uploader. When you upload an illustration to the site, it can create several smaller versions of the image. It's cool, it's powerful, and you can (need) use it. Keir Whitaker discusses the use of this feature in his article “ Automatic Responsive Images in WordPress ”.

This technique, of course, is suitable not only for WordPress. I am sure that the same tool exists (or can be bolted) to any CMS.

Can I wait for the future?

The release of the "new iPad" (that is, the third, we note for the future) has led to the emergence of many of these technical tools and their discussions. The high pixel density of the new iPad is excellent when displaying vector images or large photos, but it is not particularly suitable for small icons that have to stretch to their size and which therefore look blurry. But shipping high-resolution icons means increasing file size and slowing down sites. Therefore, it is necessary to deliver them only in those circumstances when they are needed by the reader.

Web standardizers are aware of this issue. Her discussion is devoted to the whole group . In time, they can solve this problem - and we can begin to use the means that are offered to us (suppose that these means prove to be much better than the current ones).

Perhaps we will switch src in images by means of CSS content properties , as suggested by Nicolas Gallagher. It is possible to standardize the <picture> element. Perhaps there will be an srclist attribute in HTML or a src property in CSS . It may be a prefix .