USWDS-proposals: Text input web component pre-alpha #17
Conversation
Next steps
|
There was a problem hiding this comment.
@amyleadem I've run prettier on the markdown file (via VS Code prettier plugin) for consistent formatting.
Thanks for putting this together. The thoughts I added aren't blocking, but curious to see what you think. I also left additional comments for improvements.
| | -- | Required | Add indicator that field is required | `required` prop | | ||
|
|
||
| > [!note] | ||
| > Textarea is currently bundled with the text input in USWDS 3. Because its html structure requires the `<textarea>` tag instead of the `<input>` tag, I propose that we create a separate custom element for `<usa-textarea>`. |
There was a problem hiding this comment.
thought: Makes sense to start out separate.
| > Textarea is currently bundled with the text input in USWDS 3. Because its html structure requires the `<textarea>` tag instead of the `<input>` tag, I propose that we create a separate custom element for `<usa-textarea>`. | ||
|
|
||
| > [!note] | ||
| > We could consider including some custom styles for common text input types, like `tel`, `email`, etc. I imagine we could add an icon prefix for these types when appropriate. However, this might be too opinionated and we can instead let users choose to add a prefix with the `prefix-icon` prop. |
There was a problem hiding this comment.
thought: Beyond scope, but good to capture the enhancement nonetheless.
| | Property | Description | Expected values | | ||
| | ------------- | -------------------------------- | --------------- | | ||
| | `prefix` | Add content for an input prefix | `string` | | ||
| | `prefix-icon` | Add icon for an input prefix | Name of icon | |
There was a problem hiding this comment.
question: Could this be combined with suffix-icon? Not quite seeing the benefit of having them separate at the start.
If possible, we should take a light approach to the API at the start.
There was a problem hiding this comment.
I am not quite understanding how that would work. Can you give me more info about what you are thinking?
I can see that it might make sense to combine prefix and prefix-icon though 🤔
There was a problem hiding this comment.
@amyleadem the icon will be the same whether we add it before/after the input. We should follow DRY principles and try to avoid duplicating the prop for the essentially the same icon.
Maybe I'm misunderstanding how the variant will be implemented. I think shoelace has a good example of this.
<!-- Icon prefix -->
<usa-text-input>
<usa-icon name="mail_outline" slot="prefix"></usa-icon>
<label for="input-type-text">Text input label</label>
<input id="input-type-text" name="input-type-text" />
</usa-text-input>
<!-- Text prefix -->
<usa-text-input>
<span slot="prefix">Email:</span>
<label for="input-type-text">Text input label</label>
<input id="input-type-text" name="input-type-text" />
</usa-text-input>
web-components/text-input.md
Outdated
| | Part name | Element | | ||
| | --------- | --------- | | ||
| | `input` | `<input>` | | ||
| | `label` | `<label>` | |
There was a problem hiding this comment.
issue: The input and label are light DOM elements. It doesn't seem necessary to have them as part, unless I'm misunderstanding this section.
There was a problem hiding this comment.
I might be misunderstanding, but I thought we needed to make the part available in the shadow DOM in order to give users access to style it.
There was a problem hiding this comment.
MDN link in comment says it's for styling elements in a shadow tree.
There was a problem hiding this comment.
Removed the listed parts in f3270ab
web-components/text-input.md
Outdated
| - Should textarea be its own custom element (ie, `<usa-textarea>`)? | ||
| - Should hint text be a prop or a slot? | ||
| - Is there ever a need to change the location of hint text? (maybe after the input?) | ||
| - Are input mask, character count, etc distinct custom elements? How do these components interact with this? |
There was a problem hiding this comment.
polish: Numbering the questions could help clarity when addressing them.
| - Should textarea be its own custom element (ie, `<usa-textarea>`)? | |
| - Should hint text be a prop or a slot? | |
| - Is there ever a need to change the location of hint text? (maybe after the input?) | |
| - Are input mask, character count, etc distinct custom elements? How do these components interact with this? | |
| 1. Should textarea be its own custom element (ie, `<usa-textarea>`)? | |
| 2. Should hint text be a prop or a slot? | |
| 3. Is there ever a need to change the location of hint text? (maybe after the input?) | |
| 4. Are input mask, character count, etc distinct custom elements? How do these components interact with this? |
- It makes sense. Ideally we'd extend text input, but the API seems too different. For example, we might not want textarea with icon prefix/suffixes.
- Probably easier for now to have
hintbe a prop. - If it's a prop, we can control this. If we're talking multiple hints, this should be named something else or we should make hint a light DOM element.
- Yes, they have different API's. We'd need to extend or have distinct implementations if LOE is moderate+.
Co-authored-by: James Mejia <james.mejia@gsa.gov>
|
@mejiaj I addressed your comments to the best of my ability. This is ready for your re-review. Let me know if you want to talk through anything. |
There was a problem hiding this comment.
@amyleadem thanks for updating. This looks good. I've added two additional clarifying comments.
We should be careful of adding too many props from the start. Especially if they're potentially duplicative.
Summary
Design the code structure for the text input web component.
Related issue
Closes uswds/web-components#111
Preview link
Pre-alpha for text input
Tasks
Testing and review