The responsive image team has been meeting regularly for a while. After our meeting earlier this week, we realized that make/core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. needs an update on what’s been going on with the RICG (Responsive Images Community Group) feature plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., as well as to request feedback on a few questions.
Our meetings are in #feature-respimg each Friday at 1900 UTC, 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 HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. markup which would allow developers to declare multiple sources for an image—allowing devices to 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 currently have them under consideration for development.
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
w descriptors) and
sizes attributes to the image markup generated by WordPress. According to the WordPress.org plugin directory, there are 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 A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, which can be considered separately for inclusion in core:
- Logic for producing responsive image markup
- Advanced image compression (via ImageMagick)
Responsive Image Markup
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:
- Responsive image support should be added ‘invisibly’ without introducing new settings for users to worry about.
- WordPress, out of the box, should only deal with resolution switching, and not the art direction use case for now. In other words, we would not be adding any API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. or admin (and super admin) UI User interface 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).
- Provide this functionality using default and available user-defined sizes (via
add_image_size()) for source sets rather than creating an additional set of crops. This choice is based on early feedback from Nacin regarding file-count concerns on some shared hosts.
- Provide filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. hooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. so theme/plugin authors can extend/override defaults.
- All sizes of an image (i.e.,
_wp_attachment_metadata['sizes']) with the same aspect ratio are resized versions of the same image, not custom art directed crops. This assumption has been okay so far, but there may be be plugins that replace the default image sizes with art directed crops that maintain the same aspect ratio. We’ll need to determine how to handle these cases.
Questions to Consider
- How should we handle markup embedded in post content?
- Currently, we embed the
srcset attribute directly into posts with
sizes added as a data attribute to make it easier for theme authors to filter the
sizes attribute later. It’s tricky to decide when it’s appropriate to add layout relative markup to the database, but WordPress is currently doing this to a certain extent by adding width/height attributes to images, so this may be the best solution for now.
- Instead, a more elegant solution would be to filter the content on output. This would avoid saving layout markup in the database, and extend support to posts with images that were published before the feature became available. We have a proof of concept but are unsure if adding another filter to
the_content is appropriate. Confirmation either way on this question would help us move forward.
- Should we support
sizes in older browsers?
- The plugin includes the picturefill.js polyfill, which provides support for older browsers, but would be a new dependency for core.
- We could view
- Should we turn responsive image support on by default?
- “Decisions not options.” We propose that responsive images are enabled by default in core, with filters provided for disabling or modifying the feature.
- If core does not want responsive images enabled by default, they could be enabled through a
current_theme_supports() flag. Themes would have to “opt-in” to the feature.
Advanced Image Compression
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 included them as an opt-in option within the plugin.
The updated settings are absolutely killer when there are sufficient CPU and memory resources on the host server. In our trials, file sizes have decreased by >50% compared to the default core settings.
However, on limited servers, these new settings could cause problems. We are iterating on them to find the right balance between the file-size savings and the CPU resources required to process large files.
We need your help!
New features need lots of feedback and testing. Help us test these enhancements by installing the latest version of the plugin from WordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/.
Be sure to enable advanced image compression and tell us how it does with your setup so we can gather more feedback.
If you know of plugins that heavily modify or interact with custom image sizes or art-directed crops, please leave a comment below so we can test it with this feature.
Have thoughts on the questions above? Let us know in the comments!
Want to get involved? We meet each week in #feature-respimg on Friday at 1900 UTC.