Closed jelbourn closed 1 year ago
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?
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.
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.
The Open UI Community Group just discussed [selectmenu] Rename selectmenu to selectbox
.
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.
if the name is to be changed, i think selectlist, picker or picklist would be fine replacements.
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.
I would prefer not to use selection
because the name is already used for something else.
+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
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...
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
).
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
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.
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.
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 select
alternative.
I don't have anything to back this up, just a feeling.
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
Ok, if I'm going to try and sum up the potential options (sorry AI I'm not going to list all 60):
Please use the emoji button on Github that relates to the option you'd like to vote. Please vote only once.
The Open UI Community Group just discussed Rename selectmenu to selectbox
.
As I mentioned in the conversation last week, I think SelectList
is more descriptive than SelectBox
because:
ListBox
if we propose that as a separate elementBy the definition we've discussed thus far, these components cannot contain other interactive components, so they are always a list of options.
How about selector
?
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:
- It's not always a "box" in shape
- It's a container for a list of options
ā Reply to this email directly, view it on GitHub https://github.com/openui/open-ui/issues/773#issuecomment-1654179956, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFKBQQKV5DM4Y2BKOE3TBP3XSKW3JANCNFSM6AAAAAAZNOYKM4 . You are receiving this because you commented.Message ID: @.***>
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"
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
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
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.
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?
Apologies if this has already been suggested but what about
<selectinput>
?
Could be confused with datalists I suppose? Not sure.
Still believe that selectlist is the better one here from all the things I read here.
It also just clicks in naming: "A selectlist containing a listbox"
The Open UI Community Group just discussed Rename selectmenu to selectbox
, and agreed to the following:
RESOLVED: rename `<selectmenu>` to `<selectlist>`.
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".