Responsive Images WordPress

WordPress Image Handling in a Responsive Images World

Note to the reader: This post falls under the umbrella “Morten thinking out loud”. You have been warned.

This is the first of a 2-part article. Be sure to read the 2nd part WordPress, Responsive Images, and Dynamic Image Sizes once you’re done.

The colorful light show in the underground passageway in Chicago's O'Hare Airport

Consider the image above. Depending on your screen resolution and size, the image file you are looking at will be different from the file you’d look at on a smaller or bigger screen. This is thanks to Responsive Images. And it’s really cool. That said, we have a ways to go before this new technology can truly improve WordPress and the sites it runs. And I think a large part of that work is rethinking how WordPress handles images behind the scenes. That’s what this article is about.

Responsive Images are rapidly approaching as a standard, and the RICG team are doing continuous work on a plugin that adds responsive images functionality to WordPress sites today. With any luck we’ll see the plugin baked into WordPress core in a future release and all WordPress sites will serve up responsive images out of the box.

In this article I’m not going to talk about the responsive images implementation being worked on in itself; the work being done by the group is stellar (you can follow along in the Github repo and the Slack channel) and some of the best minds in the business are working on improving the implementation. Instead I want to present some ideas about how responsive images in WordPress can change (and improve) the modality of image handling for theme and plugin developers as well as the end-user.

Status Quo: Fixed Image Sizes

Image size selection in WordPress
Image size selection in WordPress

One of the features that makes WordPress an ideal platform for introducing responsive images is its current handling of fixed image sizes:

When an image is uploaded to WordPress the application generates a series of scaled down versions of that image in addition to the original (provided the original image is larger than each of the sizes):

  • A square thumbnail (defaults to cropped 150 x 150px)
  • A medium image (defaults to max width and/or height of 300 x 300px)
  • A large image (defaults to max width and/or height of 1024 x 1024px, typically limited by theme settings)

These default sizes can be changed from admin panel under Settings -> Media, but few users touch these settings.

When the user adds an image to a post or page in the editor they can select from any of these sizes along with alignment settings to scale and position the image as desired.

The image is added with a standard <img> tag that calls in the image file for the selected size and carries with it width and height attributes to correspond with the selected size.

Theme and plugin authors also have the ability to add additional image sizes through the add_image_size(); function. This is typically used to display specific image sizes or crops in specific regions on the site, most commonly Featured Images. For brevity and to limit the scope of this article I won’t bring this into the equation.

Responsive Images Change Everything

This all works well for static images, but as we move to responsive images we have the opportunity to rethink what happens when images are generated and added to the content.

Currently the RICG Responsive Images plugin hooks in to the existing Add Media functionality and alters the HTML output of the added image to include srcset and sizes attributes. What used to look like this:

  class="alignnone size-large wp-image-1717" 

Ends up looking like this with the plugin:

  class="alignnone size-large wp-image-1717" 
  srcset="http://[]/wp-content/uploads/2015/06/DSCF2539-300x200.jpg 300w, 
          http://[]/wp-content/uploads/2015/06/DSCF2539-700x467.jpg 700w, 
          http://[]/wp-content/uploads/2015/06/DSCF2539-735x490.jpg 735w, 
          http://[]/wp-content/uploads/2015/06/DSCF2539-368x245.jpg 368w, 
          http://[]/wp-content/uploads/2015/06/DSCF2539.jpg 4896w"
  sizes="(max-width: 4896px) 100vw, 4896px"

The problem here is that because the RICG Responsive Images plugin knows nothing about the displayed size of an image, the sizes attribute has to use the max width of the image itself coupled with the width of the viewport to figure out what image file to load. As a result, if you have a gigantic image like the one in the example, and you display it on a gigantic screen or one with high resolution, the full size image (4896px wide) will load even if the displayed size is only 800px.

What we have here is a clash between old methodology and new technology. And it stems from the fact that WordPress is still an image classicist. but in a Responsive Images world it needs to be a modernist.

The solution, simple in theory and complex in execution, is for the image size drop-down to specify the sizes attribute rather than the image file size. And that sizes attribute should be controlled by the theme.

Let me explain.

New Modalities

What’s interesting about Responsive Images is that rather than thinking about images as fixed-size entities displayed in a responsive landscape we can start thinking about them as responsive containers with images inside.

Currently when you add an image to a responsive site you are in reality setting up a container and displaying the image within that container. Because the site is responsive that container will have a max-width (either specified in the container itself or constrained by an ancestral container) and will flex and resize depending on the size of the viewport. The image served up is instructed to fill the width of the container and shrink the height proportionately.

To ensure bandwidth isn’t wasted, tools like WordPress offer the user image sizes to choose from when adding an image to a post or page. These sizes in turn hard-code the maximum width and height of the img element to the size of the image.

In a Responsive Images world this makes no sense.

With Responsive Images we should only be specifying the size of the container through CSS and the sizes attribute. The browser is responsible for picking and displaying the correct image file based on the available space and display resolution. The physical size of the image, as specified in the img element is irrelevant (and should be omitted entirely imo).

This means when the user picks a size, they should not be picking a size based on the available generated files, but rather a container size based on the sizes specified by the theme developer. And if the user changes the size of the container with click-and-drag behaviors, that change should be reflected in the container through the sizes attribute.

Brave New Responsive World

This has some compelling (and quite disruptive) implications:

First of all, there is no need for the customizable Small, Medium, and Large image file sizes any more. At least not in terms of available sizes of images to be added to the site. Instead WordPress could generate some standardized sizes for small, medium, and large displays behind the scenes without ever telling the user about them. Granted, cropped versions for thumbnails and Featured Images still need to be made, but again the sizing of these can be left to a standardized function within WordPress.

Secondly, this allows theme developers (and to a degree plugin developers) to incorporate image sizes of in-post images into their designs. Because we don’t have to think about the physical size of the image any more but instead the size of the container, theme developers should be able to specify these sizes (Small, Medium, Large, whatever) in the theme and it is these container sizes, reflected in CSS and the sizes attribute, that are offered up to the user as options when an image is added.

Work is already being done in the RICG Responsive Images plugin to allow theme developers to customize the sizes attributes for images and in an ideal world I think this should become the new standard.

Finally, and this is where things get really interesting imo, there is an opening here for the possibility of doing away with image cropping all together, moving instead to cropping through CSS clipping. Because of the nature of Responsive Images as interchangeable sources, cropping can produce a large number of extraneous files, but all this is based on the old image-file-has-to-fit-container mentality from the pre-responsive images era. Since the concern now is only the container inside which the image is placed, there is no reason why a developer can’t specify positioning and crop factors using CSS, thereby not only eliminating the need for generation of cropped images, but also allowing for new and interesting behaviors like dynamic responsive cropping and user-controlled cropping on an image-to-image basis.

Overhaul Required

If  you’re with me so far one thing should be abundantly clear by this point: This change will require a complete overhaul of how images are handled by WordPress. And this overhaul is actually in progress through the work of the RICG Responsive Images team and the ImageFlow team. I’ve mulled about this to members of both teams for some time and I hope that with this post we can start the conversation in earnest and put some meat on these bones.

It is quite possible that I am off on a path into the wilderness here and that what I’m proposing is not feasible, but I am convinced this needs to be explored. Responsive Images are a fundamentally different animal from regular old images, and they require a whole new way of thinking. Trying to cage them in the old modalities of image sizes makes no sense. It is time to rethink everything. I propose we start here.

By Morten Rand-Hendriksen

Morten Rand-Hendriksen is a Senior Staff Instructor at LinkedIn Learning (formerly specializing in AI, bleeding edge web technologies, and the intersection between technology and humanity. He also occasionally teaches at Emily Carr University of Art and Design. He is a popular conference and workshop speaker on all things tech ethics, AI, web technologies, and open source.

12 replies on “WordPress Image Handling in a Responsive Images World”

I hope they implement responsive images into the core soon. I wonder if it will also remove the need of plugins like Regenerate Thumbnails.

The RICG Responsive Images feature plugin team is hard at work on this, but like I said in the article, for this to work we need to rethink the entire structure of how WordPress handles images. It’s not a small task.

Those are always the biggest challenges – “rethink the entire structure of how WP handles images”
Not only WordPress but every major project is resistent to radical changes in their core. That’s just the nature of things. Although, probably, the direction explained in the article should be where the image handling is ought to go.

Good post, btw!

I agree that these types of changes are a challenge, but in this case they are necessary. Responsive Images force us to think about images in a whole new way, and in WordPress we have the perfect platform to implement them on a large portion of the sites running on the web today thereby pushing the technology forward. I think it’s well worth the effort and strain.

Hey Morton, thanks for speaking so highly regarding those of us working on the RICG-WP plugin. This article is outstanding, and there is a lot I’ll be chewing on over the next couple of days.

One thing I’m concerned about though is image cropping. As I see it, cropping will always be necessary, because resolution switching with srcset (the majority use case) requires swapping out scaled versions of the image based on the users device resolution. Without cropping the image, you don’t have scaled versions to present to different devices.

Using only css clip path might help for art direction use cases, but you would still be loading the original image, meaning that no bandwidth is being saved for the lower resolution (and hopefully soon low bandwidth) devices. Yes, cropping does mean extra files on your server, but it also means smaller images for the client to load.

That being said, for the sizes attribute, I wholeheartedly agree, that the focus should be on the container that the image is being presented in, and not the size of the image itself. This is definitely something that theme/plugin developers should be responsible for. As for how though, that’s where things get tricky. I’m not sure WordPress can predict what the size of an image container will be, unless specified by the theme developer. Maybe we need to push the issue entirely on the theme developer, while making the sizes attribute easier to customize.

Like I said, lot’s to think about. Thanks for this article, and sorry for the ridiculously long comment!

Great article Morten, and great to meet you in person a few weeks ago in Miami!

I’ve been gnawing on the issues around responsive images in WordPress ever since I ran up against it working on a trac ticket.

The “container” concept is how I’ve been thinking about it as well, so it’s great that you’ve given us some common language for it. I agree with pretty much everything you’re proposing here except doing away with image cropping. Image cropping will still be useful for example if you upload an image that needs cropping and you’ll use the cropped version INSTEAD of the original. I do believe we should do away with the ability to crop certain image sizes but not others via the “Apply changes to:” option. That just doesn’t make sense in the responsive world.

Hey Morten,

Interesting post. I’m all for it if the WP crew can incorporate this into a future version.

What about multi resolution images (different image displayed in high res screens like my Surface Pro 3, or 5K Mac). There doesn’t seem to be an elegant solution for this, especially when using a caching system like Amazon Cloudfront.

Comments are closed.