Gutenberg: Enhancement: Inspector interface for setting pixel dimensions of image

[jasmussen]

This would be nice to have: the ability to manually set the pixel dimensions of an image. This is especially useful if you are inserting a 2x retina image, and need to set the dimensions to half of what the image is born with.

Right now the only way to do that is to enter the code editor and adjust all the dimensions there. If you only use the "Edit HTML" on the block level, you do not get access to edit the HTML hints that need to be edited in order for the block to validate.

It would be nice to simply allow these dimensions to be edited in the inspector for images.

Mockups:

We expand the Block Settings for the Image block to have additional options:

• You can choose the source thumbnail for the image in a dropdown.
• When the image size is unset, the intrinsic dimensions for the image are shown as grayed. (_Really nice to have, not critical_.)
• Pressing the Reset button will always return the dimensions to the intrinsic ones by the image.
• The pill button pattern below consists of quick shortcuts to quickly set the dimensions. For example if your image is 300x200 and you press the 50% shortcut, the dimensons for the image are explicitly set to 150x100.

[mtias]

I was thinking it would be useful to have a row of percentage values for quickly setting images in a consistent manner.

We would even make this extensible so that a theme can define a specific array of values.

cc @iseulde for some of the work around floated images and @azaozz for responsive images.

[azaozz]

Recently I've been thinking quite a bit on how to best handle images. The current behaviour: default of 100% width with 50% width for floated images makes a lot of sense and covers most user cases.

This would be nice to have: the ability to manually set the pixel dimensions of an image. This is especially useful if you are inserting a 2x retina image, and need to set the dimensions to half of what the image is born with.

With the srcset and sizes attributes this works better. Generally we don't (have to) care about 2x, 3x, etc. display densities as the browser takes care of that automatically. It chooses the best image size to download and only needs to know the width of the image when it is displayed.

Of course it would be good to have support for entering pixel values in the inspector. A quirk there will be that the editor and the theme may have different width, so results may be a bit unexpected in some cases. But the "power users" will definitely love it.

Having a row of percentage values (perhaps only for floated and centered images) would also be really nice. The ability to set several images to uniform size was one of the features many users wanted back after the last major version update of TinyMCE (yep, there used to be a "step-slider" with 10% steps for image resizing in the previous "image settings" modal).

On the other hand having percentage widths for images and not knowing the theme width brings some hard to solve problems when implementing the srcset and sizes attributes. The browser has to know how wide an image will be before the CSS is applied so it can pick the best source. Currently this is done by setting the img tag width attribute in the classic editor. I'm experimenting/considering few different approaches on what/how to do it for percentages.

[noisysocks]

I'm going to look into this one.

This would be nice to have: the ability to manually set the pixel dimensions of an image. This is especially useful if you are inserting a 2x retina image, and need to set the dimensions to half of what the image is born with.

Responsive images were added in https://github.com/WordPress/gutenberg/pull/4898, which I think nicely solves this retina image use case.

Still, I agree it would be nice to be able to explicitly set an image's dimensions using the inspector.

@jasmussen: With this in mind, is the mockup in the description above up to date?

I'm experimenting/considering few different approaches on what/how to do it for percentages.

@azaozz: Where did you get to with your experimenting? 🙂

[jasmussen]

With this in mind, is the mockup in the description above up to date?

Yes. Though here's an additional one where the 100% is pressed, which simply inputs the intrinsic dimensions of the image.

CC: @karmatosed for sanity check.

[mtias]

Note that a component "ButtonGroup" was added to support the recent font size iteration, and should be used here.

[karmatosed]

Looks good to me @jasmussen, this is being asked for in feedback so good to work on and get shipped.

[jcklpe]

Hey just wanted to check in. I found this ticket through https://github.com/WordPress/gutenberg/issues/2775

Is there a way to reset manual resizing of images and return them to a responsive state in Gutenberg?

[noisysocks]

Is there a way to reset manual resizing of images and return them to a responsive state in Gutenberg?

Not yet, but pressing the _Reset_ button that we're proposing to add as part of this issue would accomplish just that.

[jasmussen]

Is there a way to reset manual resizing of images and return them to a responsive state in Gutenberg?

It's correct that there will very soon be an explicit reset button, which should be somewhat obvious.

But you can still do it today, albeit in a less discoverable way, by applying and then unapplying a wide alignment.

[jcklpe]

Thank you. Good information to know. So far I'm loving Gutenberg! UX has been
huge improvement. Excited to start building my own blocks soon.

[azaozz]

Been thinking about this for a long time and got a "mini-proposal" on handling images (that may be better as a new issue?).

Currently:

• Images are inserted in the editor at full size, i.e. we force the user to download 2MB-5MB files in most cases.
• When the user saves the post without changing image source from the inspector, there is a chance front-end visitors will have to also download the huge files. That doesn't usually happen as WP adds the srcset attribute, but the sizes attribute is pretty useless as it only refers to the full size: sizes="(max-width: 6000px) 100vw, 6000px".

To fix this in the editor:

• Always insert the "large" size (1024px) images . If it doesn't exist (if the uploaded image is smaller), insert the "full" size.
• Add srcset attribute that will also list 2x large size (so images are retina ready). This is a new size and will have to be added to the default WP sizes, see below.
• Add another attribute to the <img> tag for Gutenberg images so we can recognize them easily in PHP. This is necessary as we will have to calculate the front-end srcset and sizes attributes a bit differently. Ideally that should have the attachment ID, something like data-wp-attachment-id="1234". Then perhaps can drop the "old" way of passing the ID, class="wp-image-1234" (can confirm if that would impact something else).
• Consider special handling of the width="123" attribute. In HTML 5.0 is has to be in px, but since the width of the editor is different than the width of the theme, the results would often be unexpected. This impacts mostly images that are resized when the user drags the corners. Should probably look for a better solution for this case, perhaps recalculating the number when displaying the image on the front-end according to the theme's width.

To fix this for the front-end:

• Add new default size 2x large, 2048px max width or height.
• Add some logic when processing <img> tags and adding srcset, etc. that will produce usable sizes attribute. It will depend on the new data-* attribute and take into account theme's width when calculating sizes. If we are going to recalculate hard-coded width attributes (see above), this can be done here and the values used in both attributes. Alternatively we can set the width in percentage (HTML 4.0 style) in the editor, then replace them with pixels at this point.

Am I missing something? Any other ideas or suggestions?

Edit: moved this to #6177.

[mor10]

Related: #6131 @azaozz