Image resizing issues

[timelsass]

Describe the bug
a. I don't understand the point of having drag handles on both the bottom and side when they are both just resizing the image. Intuitively I thought that dragging the left side would make the image wider, and dragging the bottom would make it taller. If these are just resizing, then why not use the standard way people are familiar with for resizing. It's a known way of interacting with resizables, and if both handles do the same thing that's a good indication that the wrong ui is in use.

b. Since I really just needed the image resized proportionally I decided to use the options in the side panel that have numbers in them. I'm not sure what these numbers are for, or what they are supposed to do. They should clearly label what they are modifying for users. I assume they are meant for changing the image width and height in pixels (px), so a label for the units should be added.

When I added an image, this is this how it was displayed with the resizing options:

After changing the height field to something smaller, the image was not resized in the editor, and the content following it moved up and the drag handle on the bottom was moved up over the image:

c. Sometimes the control in the side panel for width and height doesn't do anything at all. Most of the time it's just another way to proportionally scale the image - even though the width and height values are not linked.

d. Sometimes when I press the arrows in the input box for width and height, they go from their current value to zero, and move up and down starting from 0, which is annoying to figure out.

e. As the image in the editor can be resized proportionally, then the values for width and height should have an option to link or unlink the values inside to allow for unproportional image resizing, or in the very least these two values should be locked together in proportion so the user actually knows they can't do what they expect.

f. The image block makes me think I'm inserting an image, and consequently I don't think the cusor should be displaying the cusor for resizing a column and resizing a row. This can be confusing if resizable columns and rows are introduced into gutenberg as those are actually the cursors I'd expect to be present for that functionality.

Also see #8610

To Reproduce
Steps to reproduce the behavior:

1. Add an image to a new page/post.
2. Play around with resizing the image from the panel on the left and drag handle. Periodically I would have to reset the drag handles by changing the image size from the dropdown in the panel to another size.

Expected behavior

1. I expect that resizing an image works in an intuitive manner. This is one of the most important and most widely used blocks outside of paragraph and headings blocks.
2. I would expect dragging a handle located on the side or bottom extends the image in that direction - not resize an image in a proportionate scale.
3. I'd expect proportionate scaling to be done by the corner like everyone else would.
4. The cursor state should reflect a nwse-resize and nesw-resize in corner resizing.
5. I expect that the cursor col-resize and row-resize should be replaced with their respective ew-resize and ns-resize counterparts.
6. I expect that resizing in the side panel could be locked or unlocked for dimensions, which could be a control such as the link/unlink dashicons as a graphical way to display it with the appropriate markup for screenreaders needed there as well.
7. I expect that clicking on the up and down arrows in the number input field increments the number from where it was starting from, and not going automatically to zero as it often seems to do.
8. If the intention of this control is ONLY to scale the image up and down, then showing a ratio for the scale would be more appropriate than width height number inputs. The controls should also be updated to indicate that you can only change the scale.

Overall - I don't feel like this control provides a very good user experience or much of the functionality I'd expect one of the most fundamental blocks to have behind it. I think that introducing proper scaling and resizing would help make this block useful.

In comparing gutenberg's image block scaling, I would suggest looking at how tinymce handles image scaling as they are using appropriate cursor handles and handle placements for scaling images.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Ubuntu 18.04.1 LTS
• chrome
• Version 69.0.3497.92 (Official Build) (64-bit)

Additional context
Tested using twenty-ninteen theme and gutenberg latest svn release as well as master branch

[chrisvanpatten]

#11377 is working on a major revamp of how image scaling works under the hood. There are some limitations in WordPress we're trying to fix up to make this a better and more performant experience.

In terms of UI, I honestly never noticed that are using the row and column resize cursors instead of the more general north/south and east/west cursors, but now that you mention it… sure enough! @jasmussen by any chance do you know if that an intentional decision? I feel like if anyone would know it'd be you :) If it wasn't intentional, I agree that could be a quick win.

I also do wonder if adding a corner resize option would be more clear. I'm not sure we have time to land that before 5.0, but it is a good point — having a corner option might be more intuitively understood.

Adding needs design feedback so we can get some extra input here :)

[jasmussen]

This is a good observation. It is intentional insofar as it hasn't seemed very useful to allow you to skew the image. Additionally the handle is used in other interactions also, such as this one:

In this case, it feels right to me that the entire image is scaled up with proper aspect ratio, as that' sthe point of the block.

Similarly, the cover block is likely at some point in the future to receive a drag handle on the bottom edge, to control the height of that block. This would also not skew, since the image contents of that is a background image that's centered and set to cover.

However it is a nonstandard interaction for the Image element, and the point of this ticket seems valid to address. A solution seems to be that for a left aligned image, we show a single drag handle in the bottom right corner to indicate the direction of scale. For centered images, presumably bottom left and bottom right could have the handle. For right aligned it would be bottom left.

[timelsass]

yes I agree with that @jasmussen - I had assumed the intention was to not allow it to be skewed, but wanted to provide all my expectations when playing with the tool and control. I think given the plans for the future it makes sense to do the resize handle in the corners that you mentioned.

In the media example you're showing - I agree it feels right in that context, but it also feels like the resizing on the side of the image is trying to overcome not having resizable columns in a way. I
could see something like columns being resizable, and having an image inside of a column would make sense. In that situation the appearance of the block is the same, but i'd expect those middle resizers to move the column left/right and image scaling to work with the bottom corner method you talked about - which would help give a little more flexibility to layouts overall.

[annezazu]

I'm going through older issues and saw this one was still open. After reading through this and testing against the latest version, I'm closing this out as there aren't any active bugs mentioned in the list above and the rest is more general feedback that's been given context at this point. Feel free to reopen if that's incorrect!