New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LG-3187: Upgrade USWDS to 2.9.0 #159
Conversation
See uswds/uswds#3762 |
72b1849
to
3010e82
Compare
Regression: Banner link reverts to blue, resulting in accessibility failures. Screenshot (before): Error:
Fix: 23f63c9 Impact on other products: None, assuming upgrade, since changes are exclusive to stylesheet updates. Screenshot (after): |
Regression: USWDS upgraded the major version of Normalize.css, causing certain opinionated styling to be omitted. This causes Related: https://github.com/necolas/normalize.css/blob/master/CHANGELOG.md#400-march-19-2016 Screenshot (before): Impact on other products: None, assuming upgrade, since changes are exclusive to stylesheet updates. Screenshot (after): |
Update from research findings:
Affected variables are renamed in 9fcc61c. See: https://designsystem.digital.gov/about/releases/#version-220 |
Acknowledged and expected change: Footer text changes from Serif (Merriweather) to Sans-Serif (Source Sans Pro). Screenshot:
Related changelog: USWDS v2.3.0
Relevant variable assignment: |
Acknowledged and expected change: Line-heights on most content has changed slightly, in direct correlation with a fix in USWDS 2.2.0 to improve rounding precision of the line-height functions. This is only explicitly mentioned to affect navigation, but the affected functions ( Pull request: uswds/uswds#3100
Because this had a significant impact on visual regression testing, I was able to assess the impact of these and other changes by effectively reverting the fix: https://gist.github.com/aduth/77c4d3785666088282cee22f37acd981 The impact is noticeable only under scrutinous review of differences. Example:
|
USWDS 2.5.0 includes updates to markup for the benefit of improved accessibility.
https://designsystem.digital.gov/about/releases/#version-250 Examples updated in: 64f32de This will require corresponding markup changes in consuming projects at time of upgrade. |
USWDS 2.6.0 updates markup of search component.
https://designsystem.digital.gov/about/releases/#version-260 Examples updated in: a611187 This will require corresponding markup changes in consuming projects at time of upgrade. |
USWDS 2.7.0 updates markup guidance for numeric input fields:
https://designsystem.digital.gov/about/releases/#version-270 Examples updated in: 231ebd3 This will require corresponding markup changes in consuming projects at time of upgrade. |
USWDS 2.7.1 updates markup of SVG images to include
https://designsystem.digital.gov/about/releases/#version-271 Examples updated in: a67fff0 This will require corresponding markup changes in consuming projects at time of upgrade. As a general accessibility best-practice, it could be implemented independently from the LGDS upgrade in consuming projects. |
Marking this as ready for review, since all necessary changes from upgrades should be accounted for. Preview on Federalist: https://federalist-2f194a10-945e-4413-be01-46ca6dae5358.app.cloud.gov/preview/18f/identity-style-guide/aduth-uswds-upgrade/ I'm planning to include a CHANGELOG.md file to help document some of the above-noted required changes for consuming projects. Also noting: The build failure for |
USWDS 2.8.0 updates markup of the "official government website" banner. https://designsystem.digital.gov/about/releases/#version-280 Updated in documentation site in: 029b089 This will require corresponding markup changes in consuming projects at time of upgrade. |
edd78fb
to
191a314
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, looks like there is a visual regression in the accordion but it looks like mostly padding and I'm OK with it if you are
$theme-color-disabled: 'site-disabled-grey'; | ||
$theme-color-disabled-dark: 'site-darker-grey'; | ||
// TODO: Revert back to `map-get` once https://github.com/uswds/uswds/pull/3762 is released. | ||
$theme-color-disabled-light: 'gray-5'; // map-get($site-palette, 'site-lightest-grey'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we standardize on gray
vs grey
? (looking at $theme-color-disabled-family
above). My inclination is to use gray
because that's standard for US English?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we standardize on
gray
vsgrey
? (looking at$theme-color-disabled-family
above). My inclination is to usegray
because that's standard for US English?
tl;dr: I think so, yes.
It might be worth getting broader UX feedback here, but it kinda seems like the whole set of $theme-color-grey
variables should be eliminated altogether. At least comparing to the base USWDS theme color tokens, I don't see any reference to where grey originates from. Grays appear to fit within the "base" family, and we only reference grey under the base colors in our own color guide.
It may make sense to keep our own $site-palette
, but considering that USWDS spells it as gray
in their own system tokens, I agree it'd make sense to align it.
In the short-term though, I'm a bit wary to include it here, since it has some cascading effects, but in terms of making breaking changes in one pass, it could be wise to do before publishing a version of this package that contains USWDS 2.9.0.
Yeah, the prior comments worked to mitigate most of the major differences, but the remaining diff is attributed to a new line height calculation that's expected (#159 (comment)). |
Avoid duplicate overflow, allow margins to collapse as before
**Why:** Two elements may have this class, and only one should have overflow applied.
191a314
to
fd300a6
Compare
fd300a6
to
67ddf89
Compare
Couple more findings that will need reconciliation:
|
As far as impact is concerned, a naive search appears to reveal that we don't use it anywhere: https://github.com/search?l=&q=usa-tooltip+user%3A18f&type=code I can still document the change all the same. |
**Why**: Clear up console warnings on build
Chatted with @nickttng on Slack regarding the notes in #159 (comment):
|
Another discovery I'd made is that USWDS introduces a Card component in Version 2.7.0. While there are some visual similarities to the LGDS Card component, the usage guidance is not quite the same, where the USWDS discourages standalone usage of a card. While it's an unfortunate naming collision, the implementation of the LGDS card using custom Recommendation: No action for now. In the future, consider how to reconcile where reconciliation could be one of (a) removing our card implementation in favor of USWDS, (b) renaming our card component if it should be distinct from USWDS card component, or (c) merge implementation and document guidance for different usage if desired to build upon USWDS card. Note that future revisions or removal of this component should consider impact to dependent applications, where it is currently used in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent work @aduth! 🚀
Related (merges to): #158Preview on Federalist: https://federalist-2f194a10-945e-4413-be01-46ca6dae5358.app.cloud.gov/preview/18f/identity-style-guide/aduth-uswds-upgrade/
This pull request upgrades USWDS dependency from ^2.0.3. to ^2.9.0 (latest).
Notes: