Replace static with Dynamic Image Sizes for inserted images

[mor10]

Proposal

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.

Rationale

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.

Challenges

• 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.

[peterwilsoncc]

#35093 was marked as a duplicate.

[jaspermdegroot]

Replying to @mor10:

I think that for images inside the content that the user should keep control over the image size, not the theme author. So the image size should remain the size that has been set in the media settings menu.

However, I do agree that constraining of images to the content width and setting the corresponding width and height attributes should be based on the current active theme, not on the one that was active while the image was inserted.

I don't agree that width and height attributes don't serve a practical purpose anymore now that we landed responsive images in core. They tell the browser the dimensions of the img element while the srcset and sizes attributes are about what to load into that element. sizes only provides the browser information to help selecting the best source. It doesn't tell the browser at what size to render the image element.

Actually the responsive image functions that we added depend on the width and height attributes. If we would leave it up to theme authors to set image dimensions in their stylesheet we wouldn't know what to set for the sizes attribute.

Theme authors would only set max-width: 100%; height: auto; and a specific width for the "thumbnail", "medium", and "large" classes. This means that full size images won't have a width set anymore, while this is important for performance. Images already get a size-[size-name|full] class by the way.

We should also look into constraining the full size image to the content width of the active theme. Currently the sizes attribute is based on the unconstrained width and the src image is always included in the srcset so in case of full size images that are wider than the content, the browser probably loads the too big uncompressed original image.

[mor10]

Replying to jaspermdegroot:

Replying to @mor10:

I think that for images inside the content that the user should keep control over the image size, not the theme author. So the image size should remain the size that has been set in the media settings menu.

What I am proposing is for the theme author to be able to define the default image sizes that fit best with the theme design. Most WordPress users never change the default settings in media, and these are arbitrary in relation to a theme design. If/when a site admin or author sets a custom image size, that image size will have precedence.

I don't agree that width and height attributes don't serve a practical purpose anymore now that we landed responsive images in core. They tell the browser the dimensions of the img element while the srcset and sizes attributes are about what to load into that element. sizes only provides the browser information to help selecting the best source. It doesn't tell the browser at what size to render the image element.

I am saying the width and height attributes are not relevant in the final HTML output. The displayed size is controlled by RICG and CSS. This is a sidebar matter anyway. I'm not invested in removing the attributes since they are not really relevant to disllay. It would just be cleaner.

Actually the responsive image functions that we added depend on the width and height attributes. If we would leave it up to theme authors to set image dimensions in their stylesheet we wouldn't know what to set for the sizes attribute.

What I'm proposing is to tie the sizes attribute to the CSS values. This would solve the problem you are outlining.