Responsive images are powerful, and at their base are concerned with providing different images based on media rules, which indicate the features of the displays upon which each image should be shown. The first thing we did here was to add the sorl-thumbnail app, which makes it easy to generate the different images needed on the fly.
Obviously, we also will need the original image source, so in our Location model we added an image field. In the upload_to() function, we use the slug when generating the storage filename, which is already required to be unique across locations, and is safe for URLs. The image is then exposed in the administration so that we can add files accordingly.
The most interesting work happens in the template, in this case. From the sorl-thumbnail app, we load the thumbnail tag library, which provides one primary {% thumbnail %} tag that is used later. Then, to provide support across more browsers for the <picture> tag that enables responsive images, we pull in the picturefill.min.js script. Because this is a polyfill—a script providing alternative support for a core feature in browsers that do not have the support natively—it needs to load and execute as early as possible for things to render properly. As such, it is added to the extrahead block, instead of being with the other scripts in the base_js or js blocks at the end of the <body>.
When a location image exists, we construct our <picture> element. On the surface, this is basically a container. In fact, it could have nothing inside of it besides the fallback/default <img> tag that appears at the end in our template, though that would not be very useful. In addition to the original image, we generate thumbnails for three different widths—480w, 768w, and 1024w—and these are then used to build additional <source> elements. Each source provides the media rule for which it should be used and a srcset of images from which to select. In our case, we only provide one image for each <source>. The location detail page now will include the image above the map and should look something like this:
When the browser loads this markup, it follows a series of steps to determine which image to load:
- The media rules for each <source> are inspected in turn, checking to see whether any one of them matches the current viewport
- When a rule matches, the srcset is read and the appropriate image URL is loaded and displayed
- If no rules match, the src of the final, default image is loaded
As a result, smaller images will be loaded on smaller viewports. For example, here we can see that the smallest size image was loaded for a viewport only 375 px wide:
For browsers that cannot understand the <picture> and <source> tags at all, the default image can still be loaded, as it is nothing more than a normal <img> tag.