Media Chat

In the regular #core-images chat this Friday, 15 April, 19:00 UTC we are planning to discuss enhancements for 4.6. So far there are four items on the agenda:

  • We are planning to add responsive images to the editor and discuss different implementation methods, e.g. saving srcset and sizes attributes to the database versus generating them on the front end. See #36475.
  • The makers of TinyMCE recently released JavaScript image tools for editing images in the browser which could replace the current server based image editor. The new editor would be quite faster, allowing you to edit and resize images before uploading them, and it would be easier to include in other scripts. This may well be a feature project over a few releases.
  • PDF preview images. See #31050.
  • Continue to improve mixed content issues on HTTPS sites. See #34945.

If you have more ideas or tickets to discuss regarding media, please join us or leave a comment here. 🙂

#4-6, #image-editor, #images, #media, #respimg

Responsive Images in WordPress 4.4

WordPress 4.4 will add native responsive image support by including srcset and sizes attributes to the image markup it generates. For background on this feature, read the merge proposal.

How it works

WordPress automatically creates several sizes of each image uploaded to the media library. By including the available sizes of an image into a srcset attribute, browsers can now choose to download the most appropriate size and ignore the others—potentially saving bandwidth and speeding up page load times in the process.

To help browsers select the best image from the source set list, we also include a default sizes attribute that is equivalent to (max-width: {{image-width}}px) 100vw, {{image-width}}px. While this default will work out of the box for a majority of sites, themes should customize the default sizes attribute as needed using the wp_calculate_image_sizes filter.

Note that for compatibility with existing markup, neither srcset nor sizes are added or modified if they already exist in content HTML.

For a full overview of how srcset and sizes works, I suggest reading Responsive Images in Practice, by Eric Portis over at A List Apart.

New functions and hooks

To implement this feature, we’ve added the following new functions to WordPress:

  • wp_get_attachment_image_srcset() – Retrieves the value for an image attachment’s srcset attribute.
  • wp_calculate_image_srcset() – A helper function to calculate the image sources to include in a srcset attribute.
  • wp_get_attachment_image_sizes() – Creates a sizes attribute value for an image.
  • wp_calculate_image_sizes() – A helper function to create the sizes attribute for an image.
  • wp_make_content_images_responsive() – Filters img elements in post content to add srcset and sizes attributes. For more information about the use of a display filter, read this post.
  • wp_image_add_srcset_and_sizes() – Adds srcset and sizes attributes to an existing img element. Used by wp_make_content_images_responsive().

As a safeguard against adding very large images to srcset attributes, we’ve included a max_srcset_image_width filter, which allows themes to set a maximum image width for images include in source set lists. The default value is 1600px.

A new default image size

A new default intermediate size, medium_large, has been added to better take advantage of responsive image support. The new size is 768px wide by default, with no height limit, and can be used like any other size available in WordPress. As it is a standard size, it will only be generated when new images are uploaded or sizes are regenerated with third party plugins.

The medium_large size is not included in the UI when selecting an image to insert in posts, nor are we including UI to change the image size from the media settings page. However, developers can modify the width of this new size using the update_option() function, similar to any other default image size.

Customizing responsive image markup

To modify the default srcset and sizes attributes,  you should use the wp_calculate_image_srcset and wp_calculate_image_sizes filters, respectively.

Overriding the srcset or sizes attributes for images not embedded in post content (e.g. post thumbnails, galleries, etc.), can be accomplished using the wp_get_attachment_image_attributes filter, similar to how other image attributes are modified.

Additionally, you can create your own custom markup patterns by using wp_get_attachment_image_srcset() directly in your templates. Here is an example of how you could use this function to build an <img> element with a custom sizes attribute:

<?php
$img_src = wp_get_attachment_image_url( $attachment_id, 'medium' );
$img_srcset = wp_get_attachment_image_srcset( $attachment_id, 'medium' );
?>
<img src="<?php echo esc_url( $img_src ); ?>"
     srcset="<?php echo esc_attr( $img_srcset ); ?>"
     sizes="(max-width: 50em) 87vw, 680px" alt="A rad wolf">

Final notes

Users of the RICG Responsive Images Plugin should upgrade to version 3.0.0 now in order to be compatible with the functionality that included in WordPress 4.4.

#4-4, #dev-notes, #media, #respimg

Responsive Images: Merge Proposal

The RICG WordPress Team is proposing a partial merge of the RICG Responsive Images plugin into core in version 4.4. Specifically, we are proposing to add native srcset and sizes support to WordPress (ticket #33641).

Purpose

As of today, the average web page currently weighs over 2 MB with the majority of those bytes being attributed to images. Screen density and display sizes continue to increase and site owners are including larger image assets to keep up, causing slower page load times for people on smaller/older devices and on slower/expensive network connections. We have the opportunity to make a huge impact on the ~25% of the web that runs on WordPress by adding responsive image support out of the box so sites can serve appropriate sizes images to all users.

Project Background

The initial plugin idea was conceived by Tim Evko and Chris Coyier in April of 2014 before becoming the basis for the official WordPress implementation from the Responsive Images Community Group last November. Since that time, the plugin has been downloaded over 40,000 times and is actively installed on over 10,000 WordPress sites. We’ve gotten input from many WP core committers during regular meetings in the #feature-respimg slack channel, and received guidance from Mat Marquis and other members of the RICG—including the same people who wrote and are implementing the responsive image HTML spec.

Implementation details

First off, the plugin does not add any UI or admin settings to core. 🙌

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.

For images embedded in post content, we have opted to add srcset and sizes using a display filter rather than writing those attributes directly to the database. You can read more about that change in our previous project update. We’ve improved the performance of the display filter and believe it’s acceptable, but are still working to improve it further.

In all cases, we have chosen to make use of the native intermediate sizes functionality in core to create alternate image sources for our srcset attributes rather than adding additional image sizes specifically for our use. This includes any user defined image sizes as long as they are resized versions (i.e., soft crops) of the file defined in the src attribute. Themes and plugins can also filter the value of the srcset attribute through included filter hooks.

For the sizes attribute, we have chosen to use sizes="(min-width: {img.width}px) {img.width}px, 100vw" as a sensible default. However, this default value can and should be filtered by themes to meet their layout needs.

Based on community feedback, we are choosing not to include a polyfill for non-supporting browsers directly in core. However, we would recommend that themes make use of Picturefill in order to provide responsive image support to the broadest set of users.

While the plugin also includes experimental image compression settings for the Imagick editor (ticket #33642), we are not proposing that those enhancements be included at this time.

Housekeeping and next steps

This is a proposal and is subject to revision based on your feedback. If you haven’t already tried out the plugin, please download and install it from WordPress.org. You can review the current code and leave feedback at the project’s GitHub repository or in #feature-respimg on Slack.

Many thanks to @mike for shepherding the project during this release cycle and @azaozz for his performance and security feedback. We’ve reached out to the accessibility team and received no objections, and we have reached out to @drew who will review the docs once a core patch is ready.

#media, #respimg

Responsive Images Feature Plugin Update

It’s been a busy week over in #feature-respimg world!

We are now using a display filter on the_content to include responsive image markup, and are looking for feedback on the approach.

Why filter on display?

  • The sizes attribute describes the intended layout of an image to a browser before the page has been rendered, so that it can choose the appropriate image source. Since the theme knows the layout best, it should be able to filter the sizes values—something that isn’t possible if we save markup within the post content.
  • Ensures future compatibility if the user changes their theme (especially if they regenerate thumbnails) or if WordPress makes changes to the way it handles layouts.
  • Allows us to avoid accounting for the editing of image markup in TinyMCE, including directly through source, or dragging to resize.
  • Extends responsive image support to existing posts. This is the most requested feature, and a display filter is the only way—aside from bulk-modifying user content in the database—to provide this type of backwards compatibility.

Implementation

This first run uses the logic:

  • Match all images in content that include the uploads directory in their path.
  • Attempt to get the id and size from the default class attributes WordPress adds and pass those to our functions for generating srcset and sizes.
  • If this doesn’t work, try matching the image src to image paths in attachment metadata.

In our internal tests, the current filter added around 3ms per image, which will be offset in many contexts by the time saved not downloading larger than necessary image assets. That said, the performance is not ideal, and we’re working on improving it based on the conversation we had in our meeting yesterday.

How you can help

Please leave comments below or in #feature-respimg if you have feedback on the approach, suggestions for improving the filter, or if you test and can provide additional performance data.

Come get involved! Our meeting each week is on Friday at 19:00UTC in #feature-respimg.

#media, #respimg

Responsive Images Feature Plugin Update

Following up on our first official project update, here’s a brief status update to keep everyone informed about the progress we’ve made.

Updates

  • Released v2.4.0 early last week, fixing several bugs and adding a few filters (changelog). Please test on your sites and leave us feedback!
  • Created placeholder tickets for adding srcset and sizes support ( #33641 ) and improving the compression settings of Imagick ( #33642 ).
  • @jaspermdegroot is digging into the content filter approach to support responsive images for old posts. Performance tests and details on GitHub. Feedback appreciated!

Next Steps

We’re ready to create an initial patch candidate for core. We’ll be working on that over the next week, with a more detailed update at that time.

Check out the logs from our last meeting and join us for the next one on Friday at 19:00 UTC in #feature-respimg.

Questions? Please leave feedback below, or ask anytime in #feature-respimg.

#feature-plugins, #media, #respimg, #updates

Update: Responsive Image Support for Core

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 Friday at 1900 UTC, 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 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, which can be considered separately for inclusion in core:

  1. Logic for producing responsive image markup
  2. 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 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 (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 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

  1. 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.
  2. 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.
  3. 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 Friday at 1900 UTC.

#feature-plugins, #media, #respimg, #updates