Repository navigation
Improve CustomSelectControl's usability around max height #49110
Description
Gutenberg's CustomSelectControl (the reimplementation of the standard <select> control) has a maximum height due to an issue reported in #19751, but this ends up making it require scrolling when it shouldn't really be necessary:
CleanShot.2023-03-15.at.13.12.07.mp4
There are two complementary ways this could be addressed.
1) Adjust the max height based on media queries. Right now, it's just a flat 400px. Increasing it based on @media (min-height: whatever) is not a silver bullet, but it would help on large displays and/or portrait-oriented displays.1
2) Make the design more compact. By default, CustomSelectControl only shows 7 or 8 items2, which is far fewer than <select> while taking up far more vertical space:
The amount of padding and margin2 can definitely be reduced while keeping the control usable3 and legible.
Values I used to create these screenshots in Storybook
[
{
"value": "default",
"label": "Default"
},
{
"value": "0",
"label": "0"
},
{
"value": "1",
"label": "1"
},
{
"value": "2",
"label": "2"
},
{
"value": "3",
"label": "3"
},
{
"value": "4",
"label": "4"
},
{
"value": "5",
"label": "5"
},
{
"value": "6",
"label": "6"
},
{
"value": "7",
"label": "7"
},
{
"value": "8",
"label": "8"
},
{
"value": "9",
"label": "9"
}
]
[
{
"key": "default",
"name": "Default"
},
{
"key": "0",
"name": "0"
},
{
"key": "1",
"name": "1"
},
{
"key": "2",
"name": "2"
},
{
"key": "3",
"name": "3"
},
{
"key": "4",
"name": "4"
},
{
"key": "5",
"name": "5"
},
{
"key": "6",
"name": "6"
},
{
"key": "7",
"name": "7"
},
{
"key": "8",
"name": "8"
},
{
"key": "9",
"name": "9"
}
]
Footnotes
-
Setting the max height by calculating the amount of space available for the menu would be ideal, but that's getting a bit complex and anything like that would work best supported by simpler fallbacks like this. ↩
-
In the actual editor,
margin-bottom: 6px;is applied to the custom select list items, and this isn't present in Storybook. ↩ ↩2 -
If touch screen usability is the reasoning behind the current values, then they could be moved into a
@media (pointer: coarse). ↩
Activity
ciampo commentedon Jul 10, 2024
Thank you for the report!
While we're not going to be able to drop the
400pxmax-heightfor the current version of the component, we're about to merge an improvement that allows themax-heightto be less than 400px in case the popover meets the viewport edge.As we're starting to gather feedback for a hypothetical new version of
CustomSelectControl, I'd like us to consider allowing consumers of the component to setmin-heightandmax-heightfor the select popover (either via react props, or CSS rules). cc @WordPress/gutenberg-componentscbirdsong commentedon Jul 10, 2024
I hope you'll consider making the sizing/spacing dynamic using
@media (pointer: coarse)/@media (pointer: fine). That could make it a lot more usable for mouse users while still preserving usability for touch.ciampo commentedon Jul 11, 2024
That's a great point, and definitely something that we could/should take into account at a broader design level (cc @WordPress/gutenberg-design ).
Regarding
CustomSelectControlspecifically, I'm not sure how much of an impact that would make on the component, since its main purpose will be to allow custom option item designs provided by the consumers of the component.If a consumer doesn't need a custom item design and/or wants a more compact select popover look,
SelectControlis a good alternative.jasmussen commentedon Jul 11, 2024
Definitely on our minds, and good reminder. Nicer query too, than the previous trick used, which was
@media (hover: none).mrwweb commentedon Feb 11, 2025
Is it worth expanding this ticket to also cover the problematic lack of a minimum height or should I open a new ticket? It seems like they should get solved together.
In cases where this control appears at the bottom of a settings sidebar, it can have a height of 0 (the 2px height in the screenshot is from the borders, I believe):
mirka commentedon Oct 22, 2026
I believe the new
Selectfamily of components in@wordpress/uicover these problems nicely.