Gutenberg: Image: Address UI for picking thumbnail sizes

[jasmussen]

Right now you are inserting full images. We should leverage the option to pick a thumbnail size.

Does this live in the inspector? Or is it a step you go through when you insert the image?

Here's the UI from the old editor:

Here's the interface you get when you click the edit button on an image after it's inserted:

See also #1725.

[youknowriad]

I guess we need a REST API here to fetch the defined image sizes?

[youknowriad]

Thinking more about this, we could leverage the settings object (like here https://github.com/WordPress/gutenberg/pull/2021) to provide the available sizes.

[joemcgill]

I think we have an opportunity to totally rethink the use of the thumbnail size dropdown here. Remember, before WordPress supported responsive images, authors could assume that the image size they selected from the media modal had a 1:1 relationship with an actual image file (and its display dimensions). However, with support for srcset, an author might select a medium sized image and the browser might request a whichever file was most appropriate based on the viewport width and display density.

I'd like to decouple the display size/alignment of an image in the editor from the file size being inserted so that an author only needs to think about the intended layout, and WordPress handles selecting the right image to display using responsive images.

Morten Rand-Hendriksen really helped to clarify this idea for me while we were working on responsive images, and here's an article he wrote about it at the time.

What I would suggest, for now, is that we support srcset and sizes in the editor instead. If a step in the inspector is needed, it should be for authors to select a crop/dimention size (e.g., 1:1 square, 4:3 rectangle, 16:9, etc.).

[mor10]

@joemcgill is 100% on the mark here. The old paradigm of adding fixed-sized images to posts and then shoehorn responsive images code on top makes no sense in a responsive images universe. The whole idea of responsive images is to allow the browser to figure out what image file to load based on various criteria. What WordPress should do is provide a container sized using CSS and tell the browser to pour whatever is the appropriate image file into that container.

From my perspective, rather than define what pixel size a specific image size is, WordPress should define relative sizes based on the post content width:

• large = 100%
• medium = 50%
• small = 25%
• thumbnail = 15% with hard square crop

Full bleed would be something like 100% + whatever padding/margin/grid-column/other thing that restricts the width of regular content.

Theme/plugin developers are then given tools to define additional sizes and redefine the existing ones, not by physical image size but by container size relative to the content area.

This doesn't technically work against how WordPress handles things now, it's just a different way of approaching the same problem: The current modality of having WordPress generate a series of predefined image sizes would stay in place. What would change is theme developers would not need to provide lists of custom image sizes to be regenerated as long as they don't need cropping. Instead, the default image sizes generated by WordPress would usually suffice to meet the needs of most displays, thus reducing the volume of images generated without impacting actual use.

Another major bonus to this approach is responsive images would work properly even for themes that do not have any level of support for this feature. Currently for a theme to leverage responsive images support for performance, a huge pile of code needs to be added. This would go away if WordPress started treating images as responsive images rather than fixed size elements.

To sum up:

• The size drop-down should just display Full bleed, large, medium, small, thumbnail and any custom size the theme developer chooses. No specification about what the physical size is (this is relatively meaningless for users anyway).
• WordPress tags the img/figure element with the appropriate class for the selected size and provides default CSS that controls displayed size as fallback in case the theme does not support the feature.
• If a user decides to manually change the size of the image container, an inline style can be generated to set the new image size.
• RICG code in the markup reflects the current theme settings, or if missing are based on a standard formula based on percentages of the max content width.

[westonruter]

In a responsive world, I think the new question to ask is not which image _size_ but which image _crop_. Different theme-defined image sizes potentially get different predefined crops, and one of these crops may be desired for a given use (e.g. head shot vs body shot). In an ideal world, you'd be able to crop any full size image at the time of selection and have the crops dynamically apply without creating a new copy of the image in the media library (see also #21819).

[mor10]

These are two separate yet related issues. WordPress needs to move away from the idea of fixed sized images as well as hard cropping.

[paaljoachim]

Is there a way to skip having 5-6 or more hard coded duplicates of each image? And instead having one image that has a base for the various responsive images? Having a thumbnail to be less kb then the largest image. Something like this I believe: http://image.intervention.io/

[mtias]

For galleries: #1450.

[junaidbhura]

@joemcgill @mor10 I think moving the logic of image sizes and their corresponsing srcset and sizes to the theme rather than in the editor would make a lot of sense for the following reasons:

1. The image sizes totally depend on the theme that is currently being used. Decoupling image sizes from the editor would make switching to a new theme really easy
2. If the image sizes are decoupled from the images, they can be used in a variety of contexts, both in the theme and wherever it is needed (maybe it's consumed elsewhere via the REST API)
3. Content editors don't need to worry about image sizes. Content editors just need to add in the content, and leave the rest to developers

So for these reasons, I would suggest:

• Not adding image sizes in the editor. Maybe the images' aspect ratios when adding to the editor are defined in the theme? That way some themes can define that when an image is added to the editor, it's added in X:Y aspect ratio, while another theme would like it to be A:B? This way the back-end could sort of mirror the theme
• Slowly phase out fixed image sizes
• Build functionality to dynamically resize images as and where they are needed

Would love to hear your thoughts!

[mor10]

@junaidbhura This is pretty much exactly what I propose in my article and the corresponding Trac ticket.

http://mor10.com/wordpress-image-handling-in-a-responsive-images-world/

[mellis32]

Why was this issue closed without allowing a 'custom' option in the in Gutenberg image scaling dropdown?

As far as I can tell the only way to scale the image precisely is to edit the Media file directly? Frustrating.