feat(text-input): new xs size#22038
Conversation
✅ Deploy Preview for v11-carbon-react ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for v11-carbon-web-components ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #22038 +/- ##
==========================================
- Coverage 94.91% 94.89% -0.02%
==========================================
Files 539 539
Lines 45015 45055 +40
Branches 6352 6419 +67
==========================================
+ Hits 42727 42756 +29
- Misses 2156 2167 +11
Partials 132 132
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Just had some thoughts regarding the inline variants: So in the design spec, it shows the inline variant with and without an invalid state, with the input field having the same size in both of them. I think it's worth noting that these two components shown are technically different sizes in a dev environment: 
So for example, if an adopter was using the size of the inline text-input on the top, and then set the state to invalid afterwards, it would not look like the invalid state shown in the screenshot above. The input field would shrink to fit the error message since it's longer than the helper text. This is because let's say the TextInput is 500px wide for example, the label text, input field, and helper text all share that 500px width. If an invalid state is then set, with an error message that is longer than the helper text, since the TextInput is 500px wide, the input field has to shrink to accommodate for the error message. It would essentially look like if the invalid state in the screenshot above shrunk its input field to fit within the pink line I drew. There's also the case of text overflow. I'm not sure if long error messages are advised against or not for inline variants, but nonetheless, if the error message is super long it can wrap to 2+ lines and hang down below the input field. I've aligned the TextInput inline variant with the design spec in this PR, but let me know if this variant needs to be revisited. Right now a lot of the components do not follow the current inline variant design spec (e.g. Dropdown, MultiSelect, etc.) so I think it's still early enough to define how inline should behave. |
There was a problem hiding this comment.
Hi @maradwan26, thanks for working on this.
Everything from an XS size implementation perspective looks good to go! 🚀
Extra thanks for the detailed PR description, super helpful!
To address some of your open questions, I had to go down the history lane to find Inline Text input's introduction
- I think the Inline Text input was implemented without a design spec.
- This PR doesn't fully resolve error and warning states for Inline components, attaching screenshot for reference.
- For now, in context of this PR, your current implementation looks better than existing buggy implementation, but definitely worth having a solid opinion on all Inline field input components. I have created an issue for the same.
8959b3a
* feat(text-input): new xs size * fix: password input, flex wrap * fix(form): break word on overflow * feat(storybook): new size control and inline story * chore: update snapshots * feat(skeleton): size
Closes #21781
Partially addresses #21969
Contributes to #21786
Adds
xssize to TextInput with contextual layout token support in Web ComponentsChangelog
New
xssize and updated storybook control accordinglysizeprop/attribute to TextInputSkeleton, along with the newxssizecds--form-requirementclass not breaking words to wrap textChanged
inlinevariant with design specai-label -> invalidtoinvalid -> ai-labelinvalidTextwould not render when ininlinevariantinvalidTextdid not have the colour$text-errorwhen ininlinevariantmax-inline-sizeof the label/helper/invalid/warn-text from 128px to 142px to align with the design spec and fit "Error message goes here" into one line and not overflow into a second lineRemoved
cds--label--inline--lgclass from the stylesTesting / Reviewing
xs,sm,md, andlgshould render as expectedPR Checklist
As the author of this PR, before marking ready for review, confirm you:
[ ] Wrote passing tests that cover this change