ColorPicker: Remove horizontal scrollbar when using HSL or RGB color input types

[andrewserong]

What?

Raised in the review for #41222 (review):

In the ColorPicker component, ensure that the range controls in their 100% position don't cause the component to overflow and create a horizontal scrollbar when used in a popover.

Also, ensure that the bottom margin / padding of the input fields is consistent between each color input type.

Why?

It appears that the RangeControl component's slider handle (intentionally) overflows the width of the control so that the handle is more visible — the drawback is that this can cause this particular Popover to overflow. To fix this, we can give the component a little more breathing room. It seemed safer to fix it here, than to update the RangeControl directly, where it could adversely affect other instances of that component.

How?

• Add a little more wrapping to the color input control components so that we can set different padding for the header area versus the input fields.
• Set a larger amount of padding and adjust the margin for the RangeControl sliders for the HSL and RGB inputs so that the 100% position doesn't overflow the container.
• Update the bottom padding to ensure that in its full height size, there's no vertical scrollbar, and that the bottom padding is consistent between Hex, RGB, and HSL inputs.

Testing Instructions

To more clearly see when there's a horizontal scrollbar, if you're running macOS, go to System Preferences > General > Show scroll bars, and set it to Always.

1. Before this PR, open up the post editor and add a paragraph.
2. Go to set a background color and set a custom color.
3. Switch between the different kinds of color inputs, and notice that the bottom spacing is inconsistent between Hex and the two other controls (RGB and HSL)
4. Notice that RGB and HSL have a horizontal scrollbar if at least one range control slider is set to 100% (an easy way to test this is to set to white in RGB)
5. After this PR, there should be consistent bottom padding between color input types, and there should be no horizontal scrollbar

(Note: in Storybook, the ColorPicker component is not rendered in a Popover, so it's best to test this component change in the editor)

Screenshots or screencast

RGB Before	RGB After
Hex Before	Hex After

[andrewserong]

Lena and Marco — I've added you both as reviewers, but there's no urgency with this one at all as I'll be finishing up for the week shortly and am AFK on Monday 🙂

[glendaviesnz]

Tested well for me.

[ciampo]

Code changes LGTM 🎉 I'll ping @jameskoster in case he has the time to take a look from the design perspective too!

[jameskoster]

It's mostly working well, but I do still see a horizontal scrollbar appearing intermittently (with scrollbars set to always display in macOS sys prefs):

scroll.mp4

Almost certainly unrelated, but another strange issue – when you drag the range to its minimum, the adjacent text input displays the maximum value.

[mirka]

FYI I believe ColorPalette is the component you're looking for in the Storybook for testing — it's the one that has ColorPicker wrapped in a popover ✨

It's mostly working well, but I do still see a horizontal scrollbar appearing intermittently

Yes, it looks like the main color picker dot (.react-colorful__pointer) is overflowing the container. I looked into this and noticed this line here:

gutenberg/packages/components/src/color-palette/style.scss

Lines 29 to 30 in 2fa50a6

	.components-dropdown__content.components-color-palette__custom-color-dropdown-content .components-popover__content {
	overflow: visible;

I think this is what we want (vis-à-vis the dot, and maybe even the sliders?), and it's certainly the intent of the code. However, there's some JS somewhere that's adding an inline style that's overriding the overflow:

So if you overflow: visible !important, it's fixed. I have a feeling this is a regression (cf. the screenshot in #36963). It would be nice to get to the root of this, but if all else fails, maybe we resort to !important 😅

[mirka]

This hack feels weird to me, in that hex-input doesn't need to be HStacked nor have spacing — this Spacer is only being used for the default margin-bottom that comes with it.

This might have hidden complexity that I'm missing so it's not a blocker for this PR, but I feel like the CSS structure should be refactored to be more like this:

This way we can use flex gap instead of the Spacer's margin-bottom, and don't have to wrestle with the final item's margin-bottom bleeding out and messing with our outermost padding.

[andrewserong]

Thanks for the reviews and feedback @mirka and @jameskoster, apologies for the delay — I switched over to some other tasks this week, but have just given this a rebase and tweaked some things a little further.

I've done the following:

• Removed the Spacer wrapper on the hex input
• Used Flex with gap to contain the sliders
• Added overflow: hidden to the .react-colorful selector to fix the other horizontal scrollbar issue — this seemed a bit easier than trying to wrestle with the Popover's settings. It looks like when the Popover was refactored to use floatingUI, the overflow: auto rule was introduced here — I think adding this rule might be okay as a pragmatic fix.
• Upped the bottom padding slightly to remove vertical scrollbar again — it turns out that the Tooltip used within the RangeControl component sets a bottom: -80% rule which forces the Tooltip on the bottom-most RangeControl to make the ColorPicker component overflow. I feel like this shouldn't really happen — the position of the tooltip in the RangeControl component probably needs to be tweaked a bit to factor in if it's this close to the edge, but a quick fix of upping the bottom padding from 16px to 20px fixes it for now.

Here's how it's looking now:

Please let know if you think there's different / better trade-offs to be made, and I can follow up next week.

Thanks! 🙇

Almost certainly unrelated, but another strange issue – when you drag the range to its minimum, the adjacent text input displays the maximum value.

Yes, that seems a bit weird, not too sure what's going on there. Happy to take a look at that separately.

[jameskoster]

This looks good to me and the scrollbar issue seems to have been fixed:

scroll.mp4

Another tangential observation, it's a bit strange how the palette popover has different styling to the custom color one. I guess I'll open an issue for that one :)

[andrewserong]

Thanks for the follow-up review and for opening up the borders inconsistency in: #41787 👍

I'll merge this one in now, and we can look at follow-ups separately 🙂