cds-snc
feat: Slots for prefix and suffix in components
Prerequisites
- [X] I've read the Contributing Guidelines.
- [X] I agree to follow the Code of Conduct.
- [X] I've searched for existing issues that already report this problem, without success.
Describe the feature request.
We would like to be able to put explanatory text directly before or after an input or select within gcds components.
Describe the use case.
Enter the last three digits of your SIN: XXX-XXX-[ ]
Describe the preferred solution.
We think this would be best implemented by exposing slots for before-elements or after-elements. Another idea might be exposing an interior template that could be modified by developers.
Describe all alternatives.
- We can place the explanatory text after the entire gcds-input, but our designers won't like this as much.
- We can put the gcds-input inside a wrapper with display:inline-block and put the explanatory text to the right side, but if there is an error message then the width of the gcds-input and its label, etc will be restricted. This wouldn't work at all for explanatory text to the left.
- We can create separate components for label and error, but then we have to manually manage the DOM representing the error, as well as the error state on the input/select.
Provide related code or examples.
No response
Add other relevant resources.
No response
We received a similar question about whether "$" could be added to the input (in English it would be ahead of the field, in French after).
There are some known accessibility issues with putting explanatory text after the field. It could get chopped, pushed to the next line, or simply missed. We could explore the accessibility of including unit of measurement in the field/container as static text.
A workaround right now would be to include the unit of measure in the input (or other component) hint text.
Putting the text "inside" the input would be fine by us.
(That being said, I imagine you would have the same accessibility issue whether the text appears inside the input or outside? I'd imagine that your implementation probably has an actual input element somehow inside of it that the helper text will still be outside of? But hey, any reasonable implementation which gets text before and after the user-input space is a-ok.)