USWDS - Input: Move input width classes out of usa-form package

[amyleadem]

Summary

Moved .usa-input--[width] and .usa-input-group--[width] classes out of the usa-form package.
These classes are now generated in the usa-input and usa-input-prefix-suffix packages and can be used without the .usa-form parent element.

Note

This is an alternative solution to PR #5935 (Thanks @aduth!)

Breaking change

This is not a breaking change.

Related issue

Closes #5312

Related pull requests

Changelog PR

Preview link

• Input component
• Input prefix/suffix component
• Mailing address pattern

Problem statement

As a developer, I expect that if I include the package listed on a component's documentation (e.g. Text Input), all of the usage options documented for that component are available, so that I'm not confused by styles not existing despite being documented, or be forced to include more packages than I'd otherwise need for my optimized installation.

Solution

• Moved .usa-input--[width] and .usa-input-group--[width] class defintions into the usa-input and usa-input-prefix-suffix package, respectively.
  • Created a new $system-input-widths map in the uswds-core package so that the values can be defined in a single location
  • Used the $system-input-widths map to generate usa-input--[width] and usa-input-group--[width] classes
• Removed the max-width: none declaration from .usa-form .usa-input and .usa-form .usa-textarea to prevent specificity overrides

Testing and review

• Confirm the .usa-input--[width] and .usa-input-group--[width] classes match the CSS (class names and values) in develop
• Confirm usa-input--[width] and usa-input-group--[width] classes work as expected both with AND without a .usa-form parent on the following elements:
  • usa-input
  • usa-textarea
  • usa-input-group
  • Character count input (currently accepts the usa-input--[width] classes in develop)
  • Input mask input (currently accepts the usa-input--[width] classes in develop)
• Confirm no regressions as a result of reducing the specificity of max-width: none on .usa-form children:
  • Set $theme-input-max-width to a value less than mobile (like "card" or 15)
  • Open the local build of mailing address pattern story
  • Confirm that all elements in the form, including the zip code input, are the same width as they are in develop
• Confirm that creating $system-input-widths in uswds-core makes sense and lives in the appropriate location

[amyleadem]

question: Is this the best location for this file?

[mahoneycm]

One potential alternative is to move these to the properties file, although most of these values are set using system tokens.

https://github.com/uswds/uswds/blob/c512a8d408dddac083216d5c14088e20c58e6633/packages/uswds-core/src/styles/_properties.scss

[mahoneycm]

This is all looking and working pretty well @amyleadem ! I left a couple thoughts in comments but nothing that is necessarily a blocker.

[mahoneycm]

One potential alternative is to move these to the properties file, although most of these values are set using system tokens.

https://github.com/uswds/uswds/blob/c512a8d408dddac083216d5c14088e20c58e6633/packages/uswds-core/src/styles/_properties.scss

[mahoneycm]

LGTM! No perceived regressions from develop

Testing checklist

• Confirm the .usa-input--[width] and .usa-input-group--[width] classes match the CSS (class names and values) in develop.
• Confirm usa-input--[width] and usa-input-group--[width] classes work as expected both with AND without a .usa-form parent on the following elements:- [ ] Confirm no regressions as a result of removing max-width: none from .usa-form . usa-input and .usa-form . usa-input
• Confirm that creating $system-input-widths in uswds-core makes sense

[mejiaj]

Nice work, the new features are a nice enhancement that avoid breaking changes. Also, shoutout to @mahoneycm for the thorough review.

I tested:

• Updating $theme-input-max-width and ensure there aren't conflicts.
• Different sizes for input group for input prefix/suffix.
• Different sizes for input widths
• Compared against develop

[mlloydbixal]

Confirmed all the testing and review steps and confirmed previous requested changes look good. Approving!

[amyleadem]

@mlloydbixal @mahoneycm (cc: @aduth)

I've updated the Sass to generate explicit .usa-form .usa-input--[width] classes (see related comment for details). Can you re-review and make sure it still works as expected?

[mahoneycm]

This is working great! Great job covering all test cases and maintaining the current behaviors.

✅ ✅ ✅

Testing checklist

• Confirm the .usa-input--[width] and .usa-input-group--[width] classes match the CSS (class names and values) in develop
• Confirm usa-input--[width] and usa-input-group--[width] classes work as expected both with AND without a .usa-form parent on the following elements:
  • usa-input
  • usa-textarea
  • usa-input-group
  • Character count input (currently accepts the usa-input--[width] classes in develop)
  • Input mask input (currently accepts the usa-input--[width] classes in develop)
• Confirm no regressions as a result of removing max-width: none from .usa-form . usa-input and .usa-form . usa-input
  • Looks good. The max width from usa-form manages the max width without the need to set it individually on nested elements.
  • Should we remove range and select?
• Confirm that creating $system-input-widths in uswds-core makes sense

[thisisdano]

Nice work, this one got a bit complicated!