We’ve been meeting regularly for some time, and after our meeting today, wanted to update everyone on the status of the RICG feature plugin, and request feedback on a few open questions. Our meetings are in #feature-respimg each Friday, August 28, 2015 14:00 UTC-5, so please come and chat to give feedback or if you’re interested in helping out!
Several years ago, a ragtag group of web professionals identified a need for new HTML markup which would allow developers to declare multiple sources for an image, so devices could select the image source that was most appropriate for its own capabilities. Fast forward to today and all major browsers have either implemented these new tools or have them currently under consideration.
With that as background, the RICG has been working on an Official WordPress Feature Plugin™ to test the viability of adding responsive image support natively into WordPress. Specifically, our aim is to automatically add srcset (using w descriptors) and sizes attributes to the image markup generated by WordPress. According to the WP.org plugin directory, the plugin has over 30k downloads and over 10k active installs, so we’ve definitely seen an interest in this functionality.
There are two main pieces of functionality included in the plugin, which can be considered separately for inclusion in core:
- Logic for producing the responsive image markup
- Advanced image compression (via ImageMagick)
There is a lot to consider when proposing a change to the way WordPress outputs image markup, so I want to be clear about some of our assumptions going in:
- Support should be added ‘invisibly’ without introducing new settings for users to worry about.
- Only deal with resolution switching, not the art direction use case for now. In other words, we would not be adding any API or admin UI for outputting different cropped images at specific breakpoints. (For more information about use cases and all things related to responsive images, I’d recommend reading the terrific Responsive Image 101 series by Jason Grigsby).
- Prefer providing this functionality using default media sizes for source sets instead of creating an additional set of crops. This preference is based on some early feedback we received from Nacin regarding a need to be mindful of how many files we end up creating on shared hosts. Additionally, it’s always easier to add new sizes than it is to take them away once they’ve been added, so starting with WP defaults seems the most prudent to us.
- Automatically include user defined sizes added via
add_image_size()insrcsetlists when applicable as an easy means by which developers can extend the base set of sources available in a site. - Provide adequate filter hooks so theme/plugin authors can extend/override defaults.
- Logic currently assumes that all sizes of an image (i.e.,
_wp_attachment_metadata['sizes']) with the same aspect ratio are resized versions of the same image and are not custom art directed crops. So far this hasn’t been a problem, but some documentation and developer outreach may be needed to cover edge cases.
- How should we handle markup embedded in post content?
- Currently, we’re embed the
srcsetattribute directly into posts withsizesadded as a data attribute to make it easier for theme authors to filter thesizesattribute later. It’s tricky to decide when it’s appropriate to add layout relative markup to the database, but WordPress is already doing this to a certain extent by adding width/height attributes to images, so maybe this is the best solution right now. - Alternatively, a more elegant solution would be to filter the content on output, which would allow us to avoid decisions about saving layout markup in the database, and (as an added bonus) would immediately extend support to all posts published previous to this functionality being added in a non-destructive manner. We have an open PR in GitHub which is a proof of concept but we have been hesitant to implement this in case adding another filter to
the_contentwould be a non-starter.
- Currently, we’re embed the
- Should we polyfill
srcsetandsizessupport in older browsers?- Currently, we polyfill using picturefill.js, which is preferred because it provides support for older browsers.
- Alternatively, we could assume that this is progressive enhancement, which would allow us to avoid including a new library within core, if that is a concern. However, given that PF is being written by the very same people who are writing and implementing this spec, we believe it would be a reliable library to add.
- How should we handle plugins that are art directing the default image sizes but maintaining common aspect ratios?
- Currently, we assume these plugins will make use of provided filters to work around this issue.
- Alternatively, we could attempt to detect this issue, but …
- Should we turn responsive image support on by default?
- Currently, the plugin turns this functionality on by default, since that is the whole point of someone installing and enabling the plugin. In the spirit of “decisions not options” we would propose making responsive images default behavior in WordPress and providing filters for turning off or modifying the functionality at a developer’s discretion.
- Alternately, we could play it safe and enabled responsive images through a
current_theme_supports()flag, so sites would have to “opt in” to this functionality.
The second potential enhancement introduced through our plugin is an improvement to the default ImageMagick compression settings currently being used in core. RICG contributor Dave Newton has done great research on the best compression settings for ImageMagick and created a custom image editor for WordPress, which is bundled in the plugin as an opt-in option.
If included in core, this would not take the form of an additional editor, but instead the new settings would be merged with the current Imagick implementation.
The updated settings are absolutely killer when there are sufficient CPU and memory resources on the host. In our trials, we’re seeing >50% decreases in file size while using these settings over what core would output by default.
In order to get to these settings into a shape that is merge-worthy, we are in the process of iterating on Dave’s settings to find the right balance between file-size savings and CPU resources required to process large files.
In order to help us continue to improve on these enhancements, please install the latest version of the plugin from WordPress.org, enable advanced image compression and let us know what results you’re seeing.
Please comment below or, as mentioned above, visit our weekly meetings, which happen in #feature-respimg each Friday, August 28, 2015 14:00 UTC-5 for feedback or if you’re interested in helping out!
You might be able to add a little gravity to the intro by playing up that this is “THE OFFICIAL WORDPRESS PLUGIN OF THE etc.” status. We’re in kind of an unprecedented position where you can say “the people that wrote the spec and added these features to browsers are right here with us for consultation and QA”—it might speak to like “this isn’t just any ol’ plugin.”
I’d also maybe break out the AIC section into two paragraphs: one playing up the compression and the results (which are insane compared to WordPress defaults), and one mentioning the tradeoffs in processing cost. Otherwise this section feels a little blurry, like there’s just as much argument against as there is for.
That’s all I got. Great work, as usual—give ’em Hell, man.