Rename selectmenu to selectbox

[jelbourn]

The name "selectmenu" is a poor choice for the current interaction because it does not follow the "menu" pattern.

I have frequently seen developers use the term "menu" to describe any interaction with a popup. This leads to confusion when trying to compose interfaces from well-supported accessible patterns. Using the term "menu" for what's really a combobox here will further propagate this confusion.

I propose "selectbox" as an alternative. This name is both more concise and more accurate in its alignment with "combobox".

[brechtDR]

Not necessarily against the name change. But not a fan of the name "selectbox" and the reason behind it.

The name "combobox" is derived from the idea that it is the "options box" combined with an input element, so the "listbox" + "input" = combobox.

If you follow that terminology, then the "combobox" should be seen as just a part of the selectmenu (or other future name), which we have -> the listbox. So you "create a combobox by changing the listbox".

And because we already have the "listbox", let's keep it at one "box" to prevent confusion and tongue twisters?

[scottaohara]

sort of, @brechtDR. on window standard select elements (no multiple or size attrs) are exposed as comboboxes. it's not just text inputs + listbox popup. understand the point you're making, but it's also quite reasonable for people to think otherwise, since this distinction is not nearly as cut and dry.

i'm not sure it's anymore confusing than what people are already having to wrap their brains around when implementing custom ARIA combobox+listbox patterns - https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/

but shrug... if one can come up with a better name, then have at it :) i just like the idea of shelving selectmenu as it could then be used for a potential future role=menu > menuitem pattern, since the menu element is a lost cause for that purpose.

[brechtDR]

Completely understand the idea of changing the name, although for me, it doesn't have to necessarily. But boxes in boxes, it might be a bit personal. But I'm kind of allergic to this kind of naming. It's also the go to naming in css class names when people are out of ideas, maybe that's why. 😅 Might need a good brainstorm session for this. I'll be thinking about it.

[css-meeting-bot]

The Open UI Community Group just discussed [selectmenu] Rename selectmenu to selectbox.

The full IRC log of that discussion

<gregwhitworth> Topic: [selectmenu] Rename selectmenu to selectbox
<gregwhitworth> github: https://github.com//issues/773
<una> q+
<hdv> masonf: this one may be quick… bikeshedding about selectmenu. The issue is what selectmenu has the word “menu” in it… people might want to build an action menu but that's not what selectmenu would be for, so it could be confusing
<brecht_dr> q+
<gregwhitworth> ack una
<hdv> masonf: the proposal in the issue would be to rename to selectbox instead of selectmenu
<hdv> una: when we're talking about selectmenu in this group, is that we limit it to selectmenu experience, so that we don't have actions and things inside of the selectmenu… if we rename to 'box' we remove some of the limitations we had in the 'selectmenu' name, would make it feel more like a generic thing like a div
<hdv> una: also, selectmenus aren't always box-y
<gregwhitworth> +1 on selectbox seeming like listbox from a DX perspective
<gregwhitworth> ack brecht_dr
<scotto> q+
<hdv> brecht_dr: the word 'box' seems very generic… not against a name change but don't feel great about 'box'
<gregwhitworth> ack scotto
<hdv> scotto: one of the problems with the current name… if is supposed to be an updated version of the select element and it currently opens a listbox with options, that is semantically different from what a menu is. Options and menuitems are have very associations in tools like screenreaders
<una> q+
<masonf> q?
<gregwhitworth> ack una
<hdv> scotto: if we want this to be an updated select, removing the word menu makes sense to me as it semantically isn't a menu
<masonf> q+
<hdv> una: feels like this brings me back to listbox… it feels like a selectlist almost
<Westbrook> q+
<hdv> una: maybe that could work… the colloquial word would be select menu when you're selecting items in a list
<gregwhitworth> ack masonf
<hdv> masonf: the intention is definitely to replace the <select> not a menu
<gregwhitworth> ack Westbrook
<hdv> Westbrook: two quick things: in naming it not menu, we're in a world where input[type=checkbox] is often used to show and hide a menu… basically I want to say… people can use this stuff in all sorts of ways we can't imagine
<hdv> Westbrook: in the Spectrum ecosystem we call this pattern a picker
<hdv> gregwhitworth: in Salesforce world we're going to call this a picklist
<flackr> chooser is another synonym we could... choose
<hdv> gregwhitworth: let's try to resolve this async
<una> `selectlist`
<una> `<select type="list">`
<hdv> annevk: tangential question… is it explained in more detail anywhere why we can't extend `<select>` further?
<hdv> gregwhitworth: the original explainer has some info
<hdv> masonf: and there are lots of issues where we talked about this
<hdv> annevk: I read the current one, it's very light on background
<hdv> gregwhitworth: we do have a lot of issues that we discussed
<hdv> Jen: can you summarise the issue?
<hdv> gregwhitworth: there are security concerns if you can put anytihng inside an option
<hdv> gregwhitworth: also the parts that we're able to use in selectmenu, fully styleable and composeable, would be hard to do in select
<hdv> dandclark: another I can add is parser troubles… like when you want to use style els in selectmenu, in the current select the parser would kick you out of the select… it's not super clear how we could work around that
<hdv> [annevk in chat: “It drops them, it doesn't exit <select> ”]
<hdv> masonf: maybe it makes sense to open a fresh issue for this question? as we have some new people in the call
<hdv> gregwhitworth: or we could create a one pager, that would be my preference
<hdv> gregwhitworth: that would be easier to find later on than an isuse
<hdv> s/isuse/issue
<hdv> annevk: thanks it would help a lot for us
<hdv> annevk: to figure out what sort of limitations make it impossible

[mfreed7]

Generally, there was some support and some pushback to renaming away from <selectmenu>.

Other suggestions heard during the meeting:

• <selectmenu>
• <selectbox>
• <selectlist>
• <choose>
• <picker>
• <picklist>

Please feel free to weigh in or suggest additional names.

[scottaohara]

if the name is to be changed, i think selectlist, picker or picklist would be fine replacements.

[jelbourn]

I agree that selectlist is a better name than selectmenu.

Another name that comes to mind for me is <selection>. This is maybe too close to <select>, but does more directly/concisely describe the purpose of the control.

[dbaron]

I would prefer not to use selection because the name is already used for something else.

[luwes]

+1 for selectbox

list has the same issues than menu no?
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/list_role

---

it could be argued that selectmenu is still a form of a menu.
the option elements are similar to menuitemradio elements.

the select element is also not aligned with the abstract select role
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/select_role

[scottaohara]

it could be argued that selectmenu is still a form of a menu.

they're similar in high level UX interaction, but options are meant for selecting/returning a value typically used in form submission / validation. where as a menuitemradio are more associated with performing an action in and of itself. different expectations for the end user who is aware of what these different roles suggest per their intended use.

the select element is also not aligned with the abstract select role

The select element either invokes a listbox popup, or is exposed as a listbox if it is multi-selectable or has a size attribute with a value greater than 1. So, it absolutely is aligned with the abstract role...

[jelbourn]

it could be argued that selectmenu is still a form of a menu.
the option elements are similar to menuitemradio elements.

+1 to @scottaohara. They appear similar, but menus should never be form controls.

I think selectlist is better than selectmenu because at least there's a listbox involved, so you could rationalize the term as being from listbox rather than list. I do still think selectbox is my favorite, due to the symmetry / alignment with its actual interaction patterns (combobox and listbox).

[luwes]

The select element either invokes a listbox popup, or is exposed as a listbox if it is multi-selectable or has a size attribute with a value greater than 1. So, it absolutely is aligned with the abstract role...

my reasoning was more like how can a specific "select" named element which holds a listbox and button be 1 to 1 to the aria abstract select role for four form widgets, listbox, menu, radiogroup, and tree. it's not a direct mapping. sure the select element has some aria select behavior but the select element does more

[scottaohara]

understood. tbh i wouldn't be so concerned with that. there are other abstract roles which also likely would not align with people's general understanding of the actual UI components that users interact with, and aren't reflective of their names to boot. but most web developers shouldn't even need to know or care about such things, since they're (abstract roles) not be used by them anyway.

[gregwhitworth]

I like picklist not only because it's defining what it is but it should be a derivative of a picker in that the model will take N+1 possible selected options. This will be true of a date picker, a color picker, combobox etc. The benefit of defining picker itself semantically allows us to introduce these other ones with picker applied. That doesn't mean that the new elements must contain the word picker within theme, eg: combobox makes more sense to use than pickerbox when we get to that based on industry expectations. At any rate, my vote is for picklist and defining picker semantically.

[brechtDR]

I like picklist not only because it's defining what it is but it should be a derivative of a picker in that the model will take N+1 possible selected options. This will be true of a date picker, a color picker, combobox etc...

I agree with this.
For me a +1 on picklist

The only doubt I have is that selectlist might have a bit more of natural feel to it as a selectalternative.

I don't have anything to back this up, just a feeling.

[kbrilla]

Few options from AI
Try 1

If you want to name something similar to a select input without using the terms "select", "selectmenu", or "combobox", you can consider using alternative names such as:

1. ChoiceInput
2. OptionInput
3. PickerInput
4. DropdownInput
5. MenuInput
6. PickerBox
7. ChoiceBox
8. OptionBox
9. DropdownBox
10. MenuBox

These names convey the idea of selecting an option from a list without explicitly using the terms you mentioned. Choose a name that best fits the context and purpose of your input component.

Try 2

Certainly! Here's a list of 50 alternative names for a select input without using the terms "select", "selectmenu", or "combobox":

1. ChoicePicker
2. OptionSelector
3. PickerMenu
4. DropdownPicker
5. MenuSelector
6. PickerList
7. ChoiceDropdown
8. OptionMenu
9. SelectorBox
10. PickerDropdown
11. MenuPicker
12. ChoiceMenu
13. OptionPicker
14. SelectorMenu
15. PickerSelector
16. MenuDropdown
17. ChoiceSelector
18. OptionDropdown
19. SelectorDropdown
20. PickerMenuBox
21. MenuChoice
22. DropdownSelector
23. OptionMenuBox
24. SelectorList
25. PickerChoice
26. MenuBoxSelector
27. ChoiceDropdownBox
28. OptionPickerMenu
29. SelectorChoice
30. PickerMenuSelector
31. MenuOption
32. DropdownChoice
33. OptionSelectorBox
34. SelectorMenuBox
35. PickerOption
36. MenuSelectorBox
37. ChoiceMenuSelector
38. OptionDropdownPicker
39. SelectorPicker
40. PickerChoiceMenu
41. MenuPickerBox
42. DropdownOption
43. OptionMenuSelector
44. SelectorChoiceBox
45. PickerMenuChoice
46. MenuOptionSelector
47. ChoiceDropdownPickerBox
48. OptionPickerSelector
49. SelectorMenuChoice
50. PickerOptionMenu

Feel free to choose a name that suits your specific use case and preferences.

And I have to say OptionInput is just perfect as it have <options> inside of it.
Also OptionPicker is quite nice.
Both are quite distinct from combobox or select and do work well if You build other pickers from this element like colorpicker, datepicker, more advanced combobox etc

[gregwhitworth]

Ok, if I'm going to try and sum up the potential options (sorry AI I'm not going to list all 60):

1. 👍 Picker
2. 👎 Picklist
3. 😀 OptionPicker
4. 🎉 SelectList
5. ♥️ SelectBox
6. 🚀 Selectmenu

Please use the emoji button on Github that relates to the option you'd like to vote. Please vote only once.

[css-meeting-bot]

The Open UI Community Group just discussed Rename selectmenu to selectbox.

The full IRC log of that discussion

<gregwhitworth> Topic: Rename selectmenu to selectbox
<gregwhitworth> github: https://github.com//issues/773#issuecomment-1649976535
<hdv> masonf: this issue probably needs more time and interest. It's about renaming selectmenu to something else
<hdv> masonf: current winner by one iks 'selectbox', close runner up is 'picklist'
<bkardell_> q+
<hdv> masonf: this isn't definitive enough that we should resolve on it today
<hdv> s/iks/is
<bkardell_> q-
<hdv> masonf: people who are on social media, please share it so we get more votes in

[una]

As I mentioned in the conversation last week, I think SelectList is more descriptive than SelectBox because:

1. It's not always a "box" in shape
2. It's a container for a list of options
3. Possible confusion with ListBox if we propose that as a separate element

By the definition we've discussed thus far, these components cannot contain other interactive components, so they are always a list of options.

[dgrammatiko]

How about selector?

[kbrilla]

It’s not always a list either - for example emoticon picker or color picker. But It always has a picker and options ;) W dniu czw., 27.07.2023 o 20:23 Una Kravets ***@***.***> napisał(a):

…

As I mentioned in the conversation last week, I think SelectList is more descriptive than SelectBox because: 1. It's not always a "box" in shape 2. It's a container for a list of options — Reply to this email directly, view it on GitHub <#773 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFKBQQKV5DM4Y2BKOE3TBP3XSKW3JANCNFSM6AAAAAAZNOYKM4> . You are receiving this because you commented.Message ID: ***@***.***>

[jelbourn]

for example emoticon picker or color

From an accessibility standpoint, these would actually be an entirely different interaction pattern (role="grid") and wouldn't fit into the current model of "selectmenu"

[una]

It’s not always a list either - for example emoticon picker or color
picker. But It always has a picker and options ;)

Emoticon and color picker are both lists to me :) list of emojis or list of colors

[Th3S4mur41]

My first instinct was also to go with selectlist because there is always a list involved.

However there are already list elements in html with ul, li and dl. So writing list out would be inconsistent. Following the pattern would mean to rather use sl. But since selectmenu is something entirely different that would be confusing.

Picker is also to generic and somewhat of a conflict with potential future elements like a customizable date-picker.

So the best compromise remaining seems to be selectbox

[sirephil]

Considering names such as color-picker or date-picker, why not option-picker?

This explains the semantics without stating any specific presentation style, which (one assumes) could be radically adjusted via CSS.

[lukewarlow]

Apologies if this has already been suggested but what about <selectinput>?
To me this feels the most descriptive of what the element is.

Could be confused for people talking about a <select> input, but I imagine once this new element is supported most people are just gonna reach for it and the old one will get less usage?

[css-meeting-bot]

The Open UI Community Group just discussed Rename selectmenu to selectbox, and agreed to the following:

• RESOLVED: rename `<selectmenu>` to `<selectlist>`.

The full IRC log of that discussion

<gregwhitworth> Topic: Rename selectmenu to selectbox
<gregwhitworth> github: https://github.com//issues/773#issuecomment-1649976535
<hdv> gregwhitworth: we'll timebox this naming discussion to 10 mins
<hdv> masonf: the stated problem with selectmenu is that it isn't a “menu” and shouldn't be thought of as a menu
<hdv> masonf: there was a vote and some people shared it on their social media… we got quite a few more votes, with most votes, kind of close up, for selectlist and selectbox
<gregwhitworth> q?
<hdv> q+
<una> q+
<gregwhitworth> ack hdv
<gregwhitworth> hdv: I didn't vote for one of the winners but I agree with una that isn't a box so I agree with that approach
<gregwhitworth> ack una
<gregwhitworth> +1 to selectlist
<hdv> una: I left some comments in the issue… 'list' feels more semantic than box, box is a shape, there's always a list of options involved
<brecht_dr> q+
<hdv> una: we'll talk about listbox in a few minutes, it seems like it may become an element… if that's the case that would likely become very confusing, if we have both listbox and selectbox
<hdv> una: the comment on datepicker and colorpicker was interesting… re selectpicker
<gregwhitworth> ack brecht_dr
<hdv> gregwhitworth: at salesforce we call it picklists
<flackr> itempicker
<hdv> brecht_dr: wanted to confirm what Una said… box is like old school naming, not very descriptive
<hdv> brecht_dr: it clicks more with listbox inside of list too
<gregwhitworth> one positive that I like about selectlist over picklist is that it's replacing select
<hdv> brecht_dr: as a non native speaker 'list' sounds better to me
<hdv> [ the votes change in real time in the GH issue, 27 for selectlist, 20 for selectbox ]
<masonf> Proposed resolution: rename `<selectmenu>` to `<selectlist>`.
<hdv> gregwhitworth: for selectlist it probably is also more likely for people who know what it means
<masonf> Let's call it the <bikeshed> element
<hdv> una: one point in favour of `<selectpicker>`, which wasn't on vote, is when thinking about elements that go inside of `selectlist`, like listbox and `button`, but not `listitem`, maaybe `selectpicker` is… better?
<scotto> +1 mason
<hdv> flackr: but then it's like picking a select
<hdv> gregwhitworth: is this a formal objection?
<masonf> RESOLVED: rename `<selectmenu>` to `<selectlist>`.
<hdv> una: no