baseweb
baseweb copied to clipboard
[Select] Add "name" to override input's name
Feature description
A select element creates a UI around an HTML input element, and allows a user to its ID via the "id" attribute. However, it doesn't allow setting the "name". I would like to still identify the select within the form, but not identify it across the page (which is what ID is for).
I can (and do as a workaround right now) use
<Select overrides={{
Input: {
props: { name: myName },
},
}} />
but for a use case this typical, I should be able to just use
<Select name={myName} />
Historically, we recommended folks to use the overrides in these cases - but with that said, I am not against the top-level prop either. If we'd do this, however, we should make this a sweeping change across all input components.
Also, what other props we'd expose?
What do you all think @nadiia @sandgraham @chasestarr @tajo
Yes, "name" and "id" are ones that should be available to all form elements, but aren't always in more abstracted elements like "Select".
I see also that f.e. "rating" misses also "id". The file uploader I guess could also use "name" and "id"... anything that at some point produces an HTML "input", "select" or "textarea" element should have a way to set the name of that HTML element, and the ID of... the same HTML element I guess, or perhaps the ID of baseui's outermost wrapping element... One of the two (as long as it's consistent...).
For select in particular, I think other than this and enhancers (for which there's already #2595), it exposes pretty much everything that one could possibly need to override from the default underlying input.
It's a good point you brought up! We should add the name prop to the top-level select API.
It's a good point you brought up! We should add the
nameprop to the top-level select API.
if we do this, for consistency-sake, should we add this to all input components?
Yes, we should revisit all form components and make sure they expose id, name, aria-label, aria-labelledby, aria-describedby, required, disabled, autofocus, type, value, alt, autocomplete where applicable.
sounds great, thanks Nadiia - @boenrobot any chance you could help us shipping this by putting up diffs for each components?
I'm not sure if exposing ARIA attributes is a necessary thing to do, seeing as using correct semantics achieves the same purpose, and ARIA attributes could be automatically added based on the tree.
Also, I'm not completely sure which of those attributes are applicable where.
any chance you could help us shipping this by putting up diffs for each components?
If you mean just enumerating what needs to be added where, sure (though I'll add only the ones I'm sure of):
- [ ] button
- [ ] id
- [ ] name
- [ ] aria-label
- [ ] aria-labelledby
- [ ] aria-describedby
- [ ] autofocus
- [ ] value
- [ ] button-group (should work similarly to a (multi)select; an individual button's attributes should take precedence over the group ones)
- [ ] id
- [ ] name
- [ ] aria-label
- [ ] aria-labelledby
- [ ] aria-describedby
- [ ] required
- [ ] disabled
- [ ] checkbox
- [ ] id
- [ ] aria-label
- [ ] aria-labelledby
- [ ] aria-describedby
- [ ] value
- [ ] autocomplete
- [ ] phone-input
- [ ] name
- [ ] aria-label
- [ ] aria-labelledby
- [ ] aria-describedby
- [ ] required
- [ ] autofocus
- [ ] value ? (there exists "text", which is the value without the prefix, but since the prefix and value get submitted as a value, this means editing existing values becomes trickier, as one must manually split the value into a prefix and text part; adding a "value" that does this split according to the available prefixes and fallbacks to the full contents with the default prefix would make editing controls easier; if both "value" and "text" are specified, "text" should take precedence)
- [ ] autocomplete
- [ ] pin-code
- [ ] value ? (similar concerns to phone-input; see above; "values" contains an array of each box's values, not the entire string; admittedly, splitting this one is far easier, but still, it means special casing such values when creating the form)
- [ ] radio
- [ ] id
- [ ] aria-describedby
- [ ] autocomplete
- [ ] slider (should probably also add one or two CSS hidden inputs of type "range"; right now, it's just "div" elements, which can't be picked up by form libraries)
- [ ] id
- [ ] name (an array, analogously to "value", for min and max values' respective name)
- [ ] aria-label
- [ ] aria-labelledby
- [ ] aria-describedby
- [ ] autofocus (
trueshould autofocus on min/only thumb, but there should also be an extra option to autofocus on second thumb, e.g.'max', and a corresponding equivalent e.g.'min'that is synonymous withtrue) - [ ] autocomplete (an array for each underlying inputs' autocomplete attribute)
- [x] textarea
- [ ] file-uploader
- [ ] id
- [ ] aria-label
- [ ] aria-labelledby
- [ ] aria-describedby
- [ ] required
- [ ] autofocus
- [ ] autocomplete ? (I'm not sure if browsers would autocomplete a file in practice, but it's valid in markup, and in theory, browsers could upload certain files - e.g. an avatar - at certain places, so I guess this should be there for completeness' sake)
- [ ] files (this is the input[type=file] equivalent of value; it should map to that property of the HTMLInputElement; in case browsers later decide to use "value" for something, it's probably worth not using the name right now)
- [ ] rating
- [ ] id
- [ ] name
- [ ] aria-label
- [ ] aria-labelledby
- [ ] aria-describedby
- [ ] required
- [ ] autofocus
- [ ] autocomplete
- [ ] select
- [ ] name
- [ ] autocomplete
- [ ] datepicker
- [ ] id
- [ ] name
- [ ] aria-label
- [ ] aria-labelledby
- [ ] aria-describedby
- [ ] autocomplete
- [ ] time-picker
- [ ] id
- [ ] name
- [ ] aria-label
- [ ] aria-labelledby
- [ ] aria-describedby
- [ ] autofocus
- [ ] autocomplete
- [ ] timezone-picker
- [ ] id
- [ ] name
- [ ] aria-label
- [ ] aria-labelledby
- [ ] aria-describedby
- [ ] autofocus
- [ ] autocomplete