As designs were coded up, we initially used a single size image to separate the mental challenging of working out how responsive images should work to its own focused task.
When most of the layout and components were built, I made an inventory of all image sizes. The process was then to decide the optimal sizes to use, and between which break points. I’ll walk through one example to explain the process.
I decided on three size variants per image:
Several more could be added for more accuracy (the approach means at most sizes, images are stretched or squashed), but that increases complexity and markup size. With the current Picturefill solution, and the retina media query I’m using, markup is an issue, which you’ll see later.
The three sizes each need a hi-resolution, or retina equivalent. So the list becomes:
- Small 1
- Small 2× (where 2× means the image is at most twice the size of its non-2× counterpart)
- Medium 2×
- Large 2×
That’s 6 potential size variants per image. To reduce the number by 2, I matched size for reuse. Which looks like:
- Medium (also Small 2×)
- Large (also Medium 2×)
- Large 2×
The existing media queries on the site determine column widths, into which fit the images. So I determined breakpoints from those already in use. They are written as variables in Sass and look like this:
That’s effectively 6 breakpoints. For 3 image size variants, 2 min-width media query breakpoints are needed, using a mobile first approach. I selected the following:
- Small: No breakpoint, from 0px and up.
- Medium: Small breakpoint, 480px and up.
- Large: Medium breakpoint, 907px and up.
That could also be explained as:
- Use a small image for viewports from 0px to 479px.
- Use a medium image for viewports from 480px to 906px.
- Use a large image for viewports from 907px and upwards.
I’m sure that information could be represented much better, but my sketches only seem to confuse things further. (I might ping Tufte for some inspiration.)
Pulling together the responsive image logic
The 2 breakpoints above, dividing up the 3 image sizes, give all the information needed to determine the logic to tell Picturefill, when and what images to swap. 3 sizes, each with a retina equivalent, gives 6 conditions:
- Small non-retina: Use the Small image for non-retina viewports from 0px to 479px.
- Small retina: Use the Medium image for retina viewports from 0px to 479px.
- Medium non-retina: Use the Medium image for viewports from 480px to 906px.
- Medium retina: Use the Large image for viewports from 480px to 906px.
- Large non-retina: Use the Large image for viewports from 907px and upwards.
- Large retina: Use the Large 2× image for viewports from 907px and upwards.
Auto-sizing images with WordPress
From here I’ll refer the large hero image, at the top of the Action Photography homepage.
Here’s a video showing the different images getting swapped out with Picturefill:
For the hero image, I worked out exact sizes for small, medium, large, and large 2×. I then added those values to WordPress, so they are automatically generated when a sufficiently large image is uploaded. I set the sizes to crop as well, as I want to maintain an aspect ratio at the 3 different sizes, and prevent a portrait image from breaking the homepage.
By default WordPress has 3 sizes options built in, Thumbnail size, Medium size, and Large size. Configurable from ‘Settings’ → ‘Media’, when logged into WordPress. Additional sizes can be added to functions.php.
Writing the Picturefill markup
Refer to Picturefill on Github for instructions on its setup and use.
In the hero image example. That image is set as the featured image for a post. So the URL of each of the image size variants is required to be output in the Picturefill markup.
To get featured image, or post thumbnail, URLs, I wrote:
The URLs can then be added to the Picturefill markup:
Note the length of the retina media query markup. It’s bulky. Hence the reason adding several more image sizes becomes unwieldy.
Although in working out the first image a lot of decisions are made, effort is still involved in determining the size and set up of every other image required. The time and effort is considerable for this approach, but so was the switch to responsive design initially. For that I reason I decided to take the time to explore and test it out. The solution is good, but not perfect.
The downsides include:
- A large amount of planning and development time.
- Art directing images with this WordPress method is limited.
- Method only applies to featured images, not images added within posts for example (this plugin seems to do the job, although I haven’t tried it out and the configuration is limited: Picturefill.WP)
- After setting up sizes for all images required on this particular project, 12 versions of each image are generated automatically. Usually only 4 of those are required per image.
The upside is that despite those points, for this project, art direction isn’t required, the extra hosting space for the resizing of 12 images is acceptable, and images will not be featured in posts. Only featured images are used with the current setup. So it works very well.
These are the places I look to for my responsive image muse:
- The Filament Group
- Responsive Images Community Group
- Daan Jobsis’s very interesting articles on compressive images, a technique I’ve yet to experiment with. Retina Revolution and Retina Revolution Followup.