Right now OOUI DropdownInputWidget is using a fixed width, making it appear really wide. It would be nice if it could automatically size itself based on the width of the options like a normal <select> input.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T99567 OOUI DropdownInputWidget should allow automatically sizing based on width of options | |||
| Resolved | Esanders | T195257 Allow dropdown menus to autosize to larger than their handles |
Event Timeline
Comment Actions
Bug report at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=834458195#Help_restoring_old_menu_appearance
This fixed width also leads to items being cut-off too soon, if they are long.
Bug report at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=834458195#Help_restoring_old_menu_appearance
Comment Actions
Declining the “as small as necessary” part of the task for now. The, from UX perspective, more problematic issue of cut-off elements is resolved as @matmarex stated.
For the other request, Design has settled on this appearance and we are neither planning to do because there hasn't been a clear problem statement of why this should be changed. We're also going for an available width on inputs with a set max-width, so the dropdowns are are not a singular element here.
Comment Actions
Re-opening this as new take on T117749, that made me think about this again.
The dropdowns there are indeed overly long. We could
- use display: inline-block as general rule to make them always only current selected option wide, negative outcome here is that the width changes with each different selected option and might get very small with a short option or
- add a config option to enable inline-block on per product owner selection
It would definitely be an acceptable fit on the second of the dropdowns in case given above:
Comment Actions
We've got two options here.
Auto-size based on current value:
Auto-size based on current value with a min-width applied (exemplified 10em):
First one has got the disadvantages to change width depending on value selected already on very small textual variants{F28128463} and it looks less clean, therefore preferring variant 1.
From a technical perspective we could add it as an optional key to the widget, like display with values block (default and current default)/inlineBlock?!