Open hanneslsm opened 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?
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?
Done, @hanneslsm! I have also tweaked the title of the Issue to make it a a little bit clearer. Thanks again!
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
@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.
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.
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.
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.
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.
As a reference, this is what Figma does. Note that
https://github.com/WordPress/gutenberg/assets/17861443/2e80f7ee-e33e-4b5a-8550-acdf3f825106
We either
I think the overall goal would be 1. but for a quick fix we could go with 2.
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.
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
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
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