search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.31k stars 4.12k forks source link

Cover Block: Disable horizontal dragging #50503

Open hanneslsm opened 1 year ago

hanneslsm commented 1 year ago

Description

When trying to select the position value in the cover block, it won't me select the value but acts as a slider instead. Also, it's only possible to get out of the input field by a mouse click(not enter). The mouse click must also be on the right sidebar. Clicking on the canvas on the cover block won't help (only selecting a different block will)

Haven't tried and experienced it with other blocks than the cover block yet.

Step-by-step reproduction instructions

  1. Select cover block
  2. Try to change the value

Screenshots, screen recording, code snippet

https://github.com/WordPress/gutenberg/assets/17861443/01152b8c-c280-41a4-adfd-37e071ce911d

Environment info

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

mrfoxtalbot commented 1 year ago

This is intended and happens with other blocks.

https://github.com/WordPress/gutenberg/assets/4452464/67fca565-55f6-4350-9ffd-8c95157b80c0

That being said, in the case of the Cover Block, it works no only by dragging up and down, but also sideways, which interferes with the positioning of the image.

https://github.com/WordPress/gutenberg/assets/4452464/31733070-cd77-48c0-b1b4-aa856f0f15b1

I am not sure what fix to suggest, though. Should we disable the "dragging values" UI functionality for the Cover Block to avoid this?

hanneslsm commented 1 year ago

I am not sure what fix to suggest, though. Should we disable the "dragging values" UI functionality for the Cover Block to avoid this?

From what I can tell, only the horizontal dragging should be disabled.

https://github.com/WordPress/gutenberg/assets/17861443/0ed4090e-b063-45dc-bbb1-edfb4f4eff07

@mrfoxtalbot Can add this to the UX & Polish board, please?

mrfoxtalbot commented 1 year ago

Done, @hanneslsm! I have also tweaked the title of the Issue to make it a a little bit clearer. Thanks again!

annezazu commented 1 year ago

Let's take a step back! This control seems intentional as it controls the horizontal placement in the same way the other control handles the vertical placement. As a result, I don't believe this should be removed and I've removed it from the Polish board until we can get more clarity.

https://github.com/WordPress/gutenberg/assets/26996883/0273a1c9-7ff8-4166-8eb3-f5fbf01479a2

hanneslsm commented 1 year ago

@annezazu Please try to select the number as you would do in every other input field, so that you then can enter your new number. It is not working.

https://github.com/WordPress/gutenberg/assets/17861443/c9449f8a-14db-4d63-8228-55baf94d5009

Two input fields that look exactly identically (and are even in the same row) should also have the exactly the same behavior. If elements behave differently, there must also be a visual difference to indicate this. (No, the "Left" is not enough ... by the way, why is it "Left" and not "Right" or anything else?)

Lastly, I really don't think this behavior is needed at all when we have a much more elegant element literally on top of it that does the exactly same (changing the value by dragging horizontally). The input fields should be for what the name says, inputting the value… but as I showed, this doesn't work.

annezazu commented 1 year ago

Going to tag in @WordPress/gutenberg-design here for more thoughts. I imagine we can make the dragging less reactive to help prevent this when it comes to entering a number. I tried to look up PRs related but I couldn't track anything quite down just yet. I also think having one input that works by dragging and another that doesn't is an odd experience.

jasmussen commented 1 year ago

Thanks for the ping. I'd think this more of a question for the components group, perhaps @mirka knows?

That is to say, in my estimation steppers like these all drag up and down to increase or decrease the number and be consistent in this behavior across all similar number controls: https://wordpress.github.io/gutenberg/?path=/story/components-experimental-numbercontrol--default

There may be some custom code for the Cover inspector, since it's way out of date and may be using obsolete/deprecated controls.

richtabor commented 1 year ago

The FocalPointPicker is using FocalPointUnitControl to render those inputs.

That is to say, in my estimation steppers like these all drag up and down to increase or decrease the number

Yea, we could use UnitControl, with a % unit and it'll be on par with others. They should all work the same.

mirka commented 1 year ago

I'd think this more of a question for the components group, perhaps @mirka knows?

Yes, the horizontal dragging in the "Left" field has been the standard behavior for the FocalPointPicker component since its inception, currently used in the Media & Text block as well as the Cover block.

We can easily change this if you all think it's better UX.

https://github.com/WordPress/gutenberg/blob/eb6a8f7813b9fdafc5a68abe9c736e734d43ab98/packages/components/src/focal-point-picker/controls.tsx#L66

hanneslsm commented 1 year ago

As a reference, this is what Figma does. Note that

  1. the horizontal scrolling is only available on the icon area
  2. the cursor changes on hover (arrow) and on active (wider arrow).

https://github.com/WordPress/gutenberg/assets/17861443/2e80f7ee-e33e-4b5a-8550-acdf3f825106

We either

  1. could simulate the behaviour from Figma (instead of an icon we could use the title area "Left")
  2. change from horizontal scrolling to vertical
  3. remove the feature.

I think the overall goal would be 1. but for a quick fix we could go with 2.

jasmussen commented 1 year ago

Excellent video reference.

To keep things simple, we should split the effort in two, one being to fix the basics and use standardized componentry with no local overrides. This should ideally be a quick fix, and the benefits to consistency across the UI will be worth it, and can close this issue.

It's interesting to surface the horizontal arrow key on the icon, it could definitely be valid as an affordance to indicate the drag behavior. That said, it requires a little bit of careful thought, as the componentry do not all include icons that could afford such a hover state. For that reason, it could be good as a separate enhancement/feedback issue.

hanneslsm commented 5 months ago

This issue still exists. And it's now also in the CSS grid. A good real-life example of the issue is the following video, were Jamie obviously not intentionally "scrolls" through the values: https://youtu.be/4n-aiUtvtPE?feature=shared&t=137