BorderBoxControl: Reduce gap value when unlinked

[t-hamano]

Fixes #65207

What?

This PR narrows the width of the input field so that the BorderBoxControl component doesn't overflow the block sidebar.

This PR changes the gap of the BorderBoxControl component from 16px to 12px to prevent horizontal scrolling in block sidebars.

Why?

When a block sidebar has a scrollbar, the width of the container in which the BorderBoxControl component is rendered is 231px on Windows and 233px on MacOS.

On the other hand, the BorderBoxControl component has a width of 248px (Input field 116px + gap 16px + input field 116px). This width is larger than the container width on both Windows and MacOS.

How?

Change the input field width to 104px. This makes the entire component width smaller than the block sidebar container width.

Change the Gap value from 16px to 12px. The BorderBoxControl component still overflows its container, but the horizontal scrollbar no longer appears.

Testing Instructions

• Insert a Paragraph block.
• Open the Border setting from the Dimensions panel.
• Click the Unlink sides button.

Screenshots or screencast

In my environment (Windows OS), the number of digits that can be displayed changes from 4 to 3, but I'm sure there are very few users who want to apply a 4-digit border.

Before	After

[t-hamano]

I am wondering whether we should also change the width when linked:

gutenberg/packages/components/src/border-box-control/border-box-control/component.tsx

Lines 115 to 117 in 865a058

	width={
	size === '__unstable-large' ? '116px' : '110px'
	}

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Flaky tests detected in ceb266a.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12084951443
📝 Reported issues:

• [Flaky Test] Navigates the items list via UP/DOWN arrow keys #64334 in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js

[tyxla]

This doesn't look too good on MacOS with even 3-digit numbers for borders:

Increasing it to 108px seems to do the job for me:

I wonder if that would be an acceptable compromise on Windows as well?

[t-hamano]

Thanks for the review!

Increasing it to 108px seems to do the job for me:
I wonder if that would be an acceptable compromise on Windows as well?

At 108px, it will overflow the container width of 231px by 1px on Windows (Input field 108px + gap 16px + input field 108px = 232px).

This might be acceptable, but what do you think?

Another thing I noticed is that when I select the rem unit, the input field becomes narrower:

trunk (116px)	This PR (108px)

Personally, I think few users will want to use a radius larger than 100px, so as long as two digits are always visible, I think it's acceptable.

[tyxla]

I'm a bit worried about this solution, since we're chasing ghosts.

Would it be better if we just reduce the gap prop from 4 to 3? That would reduce the gap between the left and right control groups, and maybe fix the overflow issue, which is the primary reason for this PR?

[t-hamano]

Would it be better if we just reduce the gap prop from 4 to 3? That would reduce the gap between the left and right control groups, and maybe fix the overflow issue, which is the primary reason for this PR?

This approach prevents the horizontal scrollbar from appearing:

But the component is overflowing the container width:

Maybe this is a good approach for now 🤔

[tyxla]

I'm personally OK with this. Should we ping @WordPress/gutenberg-design just in case?

[jasmussen]

I think this one is fine to ship without changing gaps, as fixing the horizontal scrollbar is the most important. Text inputs are organically scrolling horizontally, for example you might have a default address input field where a very very long irish address might require you to use the right hand arrow-key to navigate to the end of it. What if someone wanted a 999999px border? We can only optimize for the 80% use case, and thankfully base inputs handle the rest.

What I do think we can do separately, is consider changing the default width of the inspector from 280px to potentially 284px. I also think the "rem" unit selector button can become square in aspect ratio; that might mean the 2 letter rem text might have very little padding, but since it's a text only button, that shouldn't be too big a problem. But as a unit select, I don't expect it to change size between selections, just like I wouldn't expect a select control to change sizes between selected options. A -1px letter spacing option could even be explored for the unit itself.

[t-hamano]

In this PR, I adopted the approach of changing the gap from 4 (16px) to 3 (12px). I also updated the PR description and screenshots.

What I do think we can do separately, is consider changing the default width of the inspector from 280px to potentially 284px.

This approach also works.

In fact, it only takes a 1px adjustment somewhere to make the horizontal scrollbar disappear 😅 I think we have two options: slightly increase the width of the sidebar or slightly decrease the gap of the BorderBoxControl or the width of the input field.

0e8a452468d050e67c9f4daba641b7e6.mp4

[jasmussen]

I'm happy with either, or both, including making the individual inputs not quite as wide.

[t-hamano]

What do you think about merging this PR?

This PR simply reduces the gap value from 16px to 12px. In fact, it overflows the container width, but the horizontal scrollbar never appears.

[tyxla]

I'm personally good with merging it 👍 Feel free to ship, given we have a design approval on it.