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.
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.
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
<?php add_default_image_size( $name, $css_width, $display_width ); ?>
The sizes to be defined would be
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.