Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#35093 closed enhancement (duplicate)

Replace static with Dynamic Image Sizes for inserted images

Reported by: mor10 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.6
Component: Media Keywords:
Focuses: administration Cc:



Change the behavior of the add image size selector from hard-coding width and height attributes to adding size-based classes to the <img> element to allow theme authors to define what Thumbnail, Small, Medium, and Large means. This creates Dynamic Image Sizes that change and adapt when a site owner switches from one theme to the next.

Practical Implementation

  • Create new theme feature for dynamic-images
  • When an image size is selected (eg. "medium"), the a class formatted as size-[selected-size], (eg. size-medium) is added to the <img> tag.
  • Theme developers add CSS rules for .size-thumbnail, .size-small, .size-medium, and .size-large. These rules can define whatever parameters the theme developer desires, but must include either width, max-width or both. Theme developers are also free to use media queries to change this behavior depending on viewport width.
  • Ideal, optional: Remove the width and height attributes from <img> markup as they serve no practical purpose once RICG and class-based sizing is implemented.


With Responsive Images in core, the modality of the image size selector no longer makes sense. The image size selector hard-codes pixel sizes to images added in posts and pages based on the physical width and height of the image file, but with the new srcset + sizes markup, these image sizes no longer have a real world rationale as the browser selects the image source dynamically.

I propose a change in what happens when an image size (thumbnail, small, medium, large, original) is selected from a pre-defined pixel size to a dynamic size defined by the current active theme.

This would allow theme designers and developers to add image sizes as part of their art direction and design, and displayed image sizes would change depending on the current active theme without the site owner having to make changes to individual images to make them fit.

In simple terms, move from this:


to this:


Backwards Compatibility

This has the potential of being a breaking change. The most obvious solution would be to make dynamic image sizes a theme feature along the lines of html5 comments and title-tag:

add_theme_support( 'dynamic-images' );

Practical Application

This change would work within the existing framework of how WordPress adds images because the only practical change in the actual post/page is the addition of a new class in the <img> tag.

To apply to existing posts and pages, the classes could be added by piggybacking off the dynamic rewriting of the <img> element done by Responsive Images.


  • Some authors physically resize images to fit a specific display. This in itself is a problem because it counteracts the responsive nature of the web, but it is a fact that must be considered. An implementation of Dynamic Image Sizes could cause some authors to be frustrated that their carefully sized images suddenly change display. This would likely only happen on old static-width sites as properly built themes with RWD would already override such forced sizing except for the full-width versions of images.
  • Currently an author can use click-and-drag behaviors to resize an image in the editor. This would be hard to replicate using the proposed CSS model, but is not impossible: One solution could be generating inline CSS for custom image sizes, and possibly adding a .size-custom class to the <img> tag. Another clearner option could be to remove the click-and-drag resizing option and instead provide percentage-based options. When discussing this it is important to note that such forced click-and-drag resizing goes against the natural behavior of images in a mobile-first RWD environments.

Change History (1)

#1 @peterwilsoncc
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #35094.

Note: See TracTickets for help on using tickets.