Update: Responsive Image Support for Core|#shyamis

Update: Responsive Image Support for Core by Joe McGill The responsive image team has been meeting regularly for a while. After our meeting earlier this week, we realized that make/core needs an update on what’s been going on with the RICG (Responsive Images Community Group) feature plugin, as well as to request feedback on a few questions. Our meetings are in #feature-respimg each [time relative]Friday at 1900 UTC[/time], so please come and chat to give feedback or if you're interested in helping out! Background 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—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 srcset (using w descriptors) and sizesattributes to the image markup generated by WordPress. According to theWordPress.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, 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 theart 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). Provide this functionality using default and available user-defined sizes (viaadd_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 hooks 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 sizesattribute 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 havea 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 srcset and 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 srcset and sizes as a progressive enhancement and only provide support in WordPress for newer browsers. In that case, we could drop the polyfill and save WordPress an extra JS dependency. Note that this polyfill is written by the same people writing and implementing the spec. We consider it to be very reliable. 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. Final Notes 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. 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 [time relative]Friday at 1900 UTC[/time]. Joe McGill | August 25, 2015 at 11:35 pm | Tags: media, respimg | Categories: Feature Plugins,Updates | URL: http://wp.me/p2AvED-3Iz