WordPress, Responsive Images, and Dynamic Image Sizes

This is an addendum to my article WordPress Image Handling in a Responsive Images World. If you haven’t done so already you should read it to get the background.

Responsive Images in WordPress Core opens up a previously unattainable opportunity for the application to allow theme (and plugin) designers and developers to take control over image sizes. This would produce better designs, better user experiences, and a better impression of WordPress as a whole from its users. To get there the way images are added to posts and pages needs to be reworked. I wrote about the theory of what I think needs to happen to implement Responsive Images in WordPress yesterday in the article WordPress Image Handling in a Responsive Images World. Today I want to provide some practical ideas in the form of a thought experiment of how the image insertion task could be handled in this new reality, from hereon out referred to as the “Responsive Images World”.

The Problem (Current)

Right now, if you create a new post or page in WordPress and insert an image, you get to choose the size of that image: Thumbnail, Small, Medium, Large, or Original. These sizes are not just names: They are displayed alongside physical pixel sizes set by WordPress defaults or by you if  you changed the settings manually.

Once the image is inserted, the size you picked for it becomes a physical restraint, and that physical restraint will persist if and when the theme is changed.

Presently when an image is added to a post, the image size is permanently defined at insertion. If the theme is changed, the image stays the same size.

The Opportunity (Future)

In the Responsive Images World, when you insert an image, you get to choose the size of that image: Thumbnail, Small, Medium, Large, or Full Width. These sizes are not just names: They are displayed alongside percentage values that control the container width of the inserted image in relation to the main container of the current theme. These widths are defined by the theme designer and/or developer.

Once the image is inserted, the size you picked for it is a variable that changes with the currently active theme. For one theme a Medium width image may be 40%, for another it may be 60%. When the theme is changed, the actual image container size will change with it to realize the vision of the designer.

In the Responsive Images World, image sizes are defined by the theme and change depending on what theme is currently active.

How it could work

Given the premise set out in my previous post about the implementation of Responsive Images, here’s how Dynamic Image Sizes could work in the Responsive Images World:

As we do today, when a new theme is created, the developer sets a $content_width value to specify the maximum allowed width of content displayed in the theme. This becomes the maximum width of any inserted image.

In addition, the developer sets the parameters for the default image sizes using a function similar to add_image_size() called add_default_image_size():


  add_default_image_size( $name, $css_width, $display_width ); 

The sizes to be defined would be thumbnail, small, medium, large, and full_width

The parameters created by the add_default_image_size() function define the CSS width of the image in percentages and the displayed max-width of the image in pixels. $css_width is passed to the Image Size drop-down in the UI to indicate to the user how large the image will be. $display_width is passed to the Responsive Images function to dynamically populate the last value in the sizes attribute for images inserted with this size.

The result will be that the user selects an image size (eg “medium”) and the theme developer decides what actual size that image is when displayed in the theme. Because of Responsive Images and the $display_width parameter set by the theme and linked to the sizes attribute, the theme will always work with the browser to use the ideal image file from srcset based on the actual displayed size of the image, not the maximum width set by $content_width or the viewport.


There is an obvious challenge here that requires a substantial shift in how WordPress outputs code in the browser and may cause some significant issues with caching: WordPress post (and page) HTML is stored as more or less persistent content in the database. That includes any <img> tags. However, because the sizes attribute is a presentational element embedded in the raw HTML of the page, with this new approach WordPress has to populate this value dynamically on load based on the size parameters set in the theme. In a situation where the HTML is cached this will cause problems.

Another issue: What happens if a user manually resizes an image with click-and-drag behaviors in the editor? I have no answers for that one yet, but I am sure there is an obvious answer hiding somewhere.

6 thoughts on “WordPress, Responsive Images, and Dynamic Image Sizes

  1. Hi Morten,
    I just began learning WordPress so I can move my site over from Drupal, which I have been using for four or five years. I was wasting way too much time with Drupal’s various image modules, but I was able to get responsive images to work with Drupal’s Picture module. I had that running with and Adaptive Image module which automatically scaled images to browser window size (or maybe container size?). Anyway, the picture module worked quite well for this. I just realized, on my fifth day of setting up the WP site, that the images are actually scaled, rather than redelivered according to container size. So, WP is working more like Drupal with the Adaptive Image module set up (and WP works for this right out of the box!). I did install the RICG plugin, but have not yet gotten it to deliver anything other than a scaled image. I will have to pour over the docs. Just to be clear though, that is what the RICG plugin should do, right?

  2. hmm. Looks like I need to install the picturefill js library — Guess I didn’t completely get away from getting under the hood. >grin< I plan to use a large number of photos, so I would prefer moble and tablet users to not have to dl large versions.

    Thanks again for the article!

  3. I’ve uploaded the RICG plugin to a test site I’m currently putting together. For the smaller screen and medium sized, it’s working beautifully. When the viewport has to be increased to larger desktop variants that’s where it gets a bit tricky.

    However, what’s the latest on the RICG team? They haven’t updated the plugin in over a year, will it become a part of WordPress Core?

  4. I not to mention my pals were analyzing the nice thoughts from the blog while quickly developed an awful feeling I never expressed respect to you for those strategies. All of the young men appeared to be absolutely glad to read through them and have certainly been making the most of them. Many thanks for genuinely indeed thoughtful and then for making a choice on this sort of impressive useful guides millions of individuals are really wanting to know about. Our honest apologies for not expressing gratitude to sooner.

Leave a Reply

Your email address will not be published. Required fields are marked *