An official merge proposal was created for the responsive images plugin, and during the weekly Core dev chat a lively discussion took place discussing its merits and the variety of issues with enabling responsive images in WordPress.

The candidate plugin is the official plugin from the Responsive Images Community Group, which has been leading the way on a lot of awesome responsive initiatives (and I think may now be the Responsive Issues Community Group). A lot of great work has gone into the official WordPress implementation, but there are several issues at play.

In short, the plugin hooks into a WordPress function to deliver the image, and applies in a lot of places:

The plugin adds srcset and sizes attributes to images by extending wp_get_attachment_image(), which includes all post_thumbnails, photo galleries, and any other images that use wp_get_attachment_image() to build the markup.

This means that all images in your content will enable responsive images, as will most functions you’d use to call an image like the_post_thumbnail(), which use wp_get_attachment_image() at a lower level within them.

Where things get tricky are with defined image sizes, image aspect ratios, and when images actually get called. And there’s the little thing about handling older content.

Let’s start with older content.

The team decided to use a filter on content, so that old content can take advantage of responsive image features. There is a slight (few milliseconds per images) performance hit in doing so, because parsing content is hard, but the team believes the cost will be made up with the smaller image delivery; and they also make the good point that it can get faster over time if new methods are found to be better.

The alternative to the filter would be to insert the responsive markup directly in the content, meaning new content would use the capability, and WordPress wouldn’t affect older posts. I agree the filter is the smart move here.

You may wonder what images will be made available. At its core, the plugin puts all images that are the same aspect ratio as the requested image in the srcset. So if you insert a full size image and it is 1500×1500 and your large image size is 1024×1024 (the WordPress default), it would replace the full size with the large size for smaller viewports, because it is both smaller and it is the same aspect ratio.

If an image isn’t the same aspect ratio, it wouldn’t be used; so it prevents, for example, an intended landscape image from being replaced by a vertically cropped image on a smaller screen.

The other issue that was brought up in the meeting is the wide gap between WordPress default image sizes.

• Thumbnail: 150×150 (potentially hard cropped to always be square)
• Medium: 300×300
• Large 1024×1024

So if the site owner doesn’t change the defaults and the theme doesn’t add any, then it’s feasible the image would never get switched because the available sizes are still smaller than most of the smallest screens, so large would still be used if that’s what was originally inserted.

Two of the options to account for this are to adjust current defaults or add new image sizes.

Personally I’ve always wondered why the defaults are set this way. I believe either medium or large should be defaulted to whatever the theme’s $content_width variable is, and definitely that thumbnails and medium should be bigger. I’d also like to see the height values set to null, so that the width always prevails no matter the height (this is a newish feature to the add_image_size() function).

As for new image size recommendations, it was brought up that a “master image” could be one potential new image size. That way, if the original is huge — I know you’ve all had a client upload a 6,000px image — the master image could be set at a web-reasonable max size (maybe 2,000px?). That could be the new “full size”. I know that would be a fantastic way to stand in as a new detail option for instances like clicking pictures from a gallery thumbnail.

Another idea was to automatically create 2x versions of the default images to account for retina. And that brings up the final consideration I’ll discuss in this note, so it doesn’t get out of hand. The function will deliver a 2x image when it detects a retina capable device. So if you consider our examples, even if the viewport is small enough for the smaller image, often times the smaller the device the more likely it is to be retina — so more and more of the larger images may be delivered anyway.

At the end of all of these considerations and loopholes I got kind of overwhelmed, and the core discussion of the merge proposal went on for almost an hour. But someone (I think project lead Joe McGill) brought up a great point: in the end this is a web standard that WordPress is merely implementing. There will surely be challenges with responsive images, but it is likely in our best interest to implement the standard. There are probably many ways developers will use this feature set that wasn’t discussed in the meeting.

Personally, I don’t think the biggest wins will be in content at all. I think it’ll be with the huge full screen banner images. In that case at least, smaller devices can hopefully start delivering smaller versions. Of course, smaller versions will also need to be available, so it’ll be up to theme developers to make smart decisions about aspect ratios they create in their themes, and in my opinion they need to stick to those aspect ratios as much as possible so that the srcset will have more options.

Phew, okay, that’s enough on responsive images. The merge proposal got a whole lot of thumbs up, and a patch is imminent. As long as everything looks good before the feature freeze, we should see a responsive image implementation in WordPress 4.4, and that’s a really great thing.