USWDS - Input & Prefix/Suffix: Add disabled styles. Resolves #4913#5004
USWDS - Input & Prefix/Suffix: Add disabled styles. Resolves #4913#5004mahoneycm wants to merge 28 commits into
Conversation
There was a problem hiding this comment.
No issues found with input prefix / suffix visual styles specifically. Added comments based on additional findings. Also, can you check the failed test in CircleCI?
Tested
- Code style and formatting
- Input prefix/suffix with disabled attribute
- Adding
disabledattribute to all inputs found in components underForm Inputs
Removed styles for text inputWe'll add support disabled styles for other form elements in another ticket
|
mejiaj
left a comment
There was a problem hiding this comment.
Looks good on this component. Let's create a new issue (if there isn't one already) for extending this to other form inputs.
|
Issue created here: #5051 |
|
@mahoneycm I added a comment to #5051 about possibly standardizing USWDS disabled styles since there are differing levels of contrast in disabled styles across the design system. Additionally, our radio and checkbox disabled styles have added |
|
Originally I had set the color to |
amyleadem
left a comment
There was a problem hiding this comment.
Hi @mahoneycm,
I remembered that we should add the same styles for aria-disabled as well (like in PR #4783).
I also noticed that date picker no longer has styles for aria-disabled. Can you take a look to see if your fix will repair that?
Thanks!
|
@amyleadem I noticed that other forms include As for date picker, I'll look into it as part of #5051 |
|
@amyleadem I added
|
|
Going to change the status on this issue to "Review" to allow for evaluation. |
amyleadem
left a comment
There was a problem hiding this comment.
I like this styling solution and I like the clarity of the variables up top, @mahoneycm! I added a few comments for your review.
Additionally, what do you think about the possibility of removing the index.js file now that the input is full width and absolutely positioned? I might be missing something, but with a little tweaking it feels like we can handle focus with CSS exclusively now. Curious to hear your thoughts!
|
@amyleadem Thanks for the great feedback! Resolved all of your comments if you'd like to give it a double check! |
| &--error, | ||
| &--success { | ||
| & input:focus { | ||
| outline-offset: units($theme-input-state-border-width); | ||
| } | ||
| } |
There was a problem hiding this comment.
I think the the outline-offset is a good consideration. Nice call.
There was a problem hiding this comment.
I did notice that the input border (1px) is now covered by the focus outline, whereas it was visible before. It is a small thing, but just wanted to flag the visual difference. Not sure if it needs any action.
There was a problem hiding this comment.
Look who's finally learning to use tokens 🤪
I experimented with trying to resolve the hidden input outline but I wasn't able to add on pixels to the units($theme-input-state-border-width) function and the input is being set by like so:
%block-input-styles {
@include u-border(1px, "base-dark");Maybe if they're both variables I could add them within the function?
There was a problem hiding this comment.
Agreed, good consideration. I was initially put off by the level of nesting, but it makes sense. Moving forward we should be cautious with too much nesting.
Usually it's best practice to move your grouped selectors up before the individual ones. The & isn't necessary when it's a child element.
&--error,
&--success {
// No need for the preceeding `&` here.
input:focus {
outline-offset: units($theme-input-state-border-width);
}
}
&--error {
@include u-border($theme-input-state-border-width, "error-dark");
}
&--success {
@include u-border($theme-input-state-border-width, "success");
}Compiles to:
.usa-input-group--error input:focus,
.usa-input-group--success input:focus{
outline-offset:0.25rem;
}
amyleadem
left a comment
There was a problem hiding this comment.
Looking good! I had a couple of comments for you — just some little things.
| &--error, | ||
| &--success { | ||
| & input:focus { | ||
| outline-offset: units($theme-input-state-border-width); | ||
| } | ||
| } |
There was a problem hiding this comment.
I think the the outline-offset is a good consideration. Nice call.
| &--error, | ||
| &--success { | ||
| & input:focus { | ||
| outline-offset: units($theme-input-state-border-width); | ||
| } | ||
| } |
There was a problem hiding this comment.
I did notice that the input border (1px) is now covered by the focus outline, whereas it was visible before. It is a small thing, but just wanted to flag the visual difference. Not sure if it needs any action.
mejiaj
left a comment
There was a problem hiding this comment.
@mahoneycm some minor comments, otherwise LGTM.
| &--error, | ||
| &--success { | ||
| & input:focus { | ||
| outline-offset: units($theme-input-state-border-width); | ||
| } | ||
| } |
There was a problem hiding this comment.
Agreed, good consideration. I was initially put off by the level of nesting, but it makes sense. Moving forward we should be cautious with too much nesting.
Usually it's best practice to move your grouped selectors up before the individual ones. The & isn't necessary when it's a child element.
&--error,
&--success {
// No need for the preceeding `&` here.
input:focus {
outline-offset: units($theme-input-state-border-width);
}
}
&--error {
@include u-border($theme-input-state-border-width, "error-dark");
}
&--success {
@include u-border($theme-input-state-border-width, "success");
}Compiles to:
.usa-input-group--error input:focus,
.usa-input-group--success input:focus{
outline-offset:0.25rem;
}…suffix.scss Co-authored-by: James Mejia <james.mejia@gsa.gov>
|
@mejiaj Thanks for sharing! Always happy to have a method to the madness and organize our files. I did some cleanup and pushed it up if you'd like to re review! Let me know if there's anything I can organize further! |
There was a problem hiding this comment.
Looks good! Thank you for your patience on this. Tested in Firefox, Chrome, and Safari.
Also, I went ahead and ran prettier sass task.
Odd, the original test failed in CircleCI due to a timeout. Wasn't able to reproduce locally and resolved on re-run.
|
Work implemented in #5063 |


Description
Preview →
Resolves #4913
Input disabled styling
Currently, disabled form elements other than
buttonrely on default browser styles to give visual queues that form elements are disabled. Chrome and Edge very lightly dim the field, but is sometimes hard to notice. Other browsers such as Safari and Firefox do not add any visual indication that these fields are inaccessible to the user.@amyleadem summed it up very nicely in her comment on #4322 which addresses this issue for
select / dropdowncomponentsI agree with Amy in leaning towards developing our own
disabledstyles to have a consistent and easy-to-understand style across all USWDS form elements and browsers.This PR adds
disabledstyles forinputelements but can be extended to other form elements such as text fields, drop downs, and combo boxes if we chose to take this route.Prefix / Suffix
As mentioned in #4913, input prefix/suffix does not inherit the input disabled style. This can be resolved by creating a
usa-input-group--disabledstyle. The usage would be consistent with how we implement the error state withusa-input-group--error.Prefix / Suffix are the only components that make use of the
usa-input-groupclass so there is no worry about the styles breaking another component.Screenshots
Before
Prefix with disabled input:

After
Prefix with
usa-input-group--disabledand disabled input: