-
Notifications
You must be signed in to change notification settings - Fork 1k
USWDS - Footer: Grid layout hotfix #5675
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
Conversation
This restores setting from 3.7.0
> .grid-container { | ||
@include grid-container($theme-footer-max-width); |
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.
Moving .grid-container
class to match what it was in 3.7.0
before changes were made.
uswds/packages/usa-footer/src/styles/_usa-footer.scss
Lines 26 to 34 in e670ce3
.usa-footer { | |
@include border-box-sizing; | |
@include typeset($theme-footer-font-family); | |
overflow: hidden; | |
> .grid-container { | |
@include grid-container($theme-footer-max-width); | |
} | |
} |
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.
@mahoneycm to confirm, the current state has them outside and this change brings them back under footer class?
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.
The current state has all of the grid classes nested under the footer class. This change moves them outside of the footer class to resolve specificity issues.
I maintained .usa-footer > .grid-container
to match 3.7.0
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.
@mahoneycm a few questions:
- Does this create duplicate styles in the final CSS file?
- If so, is there a negative impact on performance?
- Is there a method that can help us avoid specificity issues or duplicating styles (for example:
:where()
— baseline browser support or a flag to check if grid sass has loaded) ?
Here's how I understand the issues:
- The specificity negatively impacts users.
- Guidance is needed to direct users to load
usa-layout-grid
.
Is that correct?
Question response1. Does this create duplicate styles in the final CSS file?
2. If so, is there a negative impact on performance?
3. Is there a method that can help us avoid specificity issues or duplicating styles (for example:
|
@mahoneycm thanks for looking into my questions. We should have guidance about the layout grid dependency on the website (if we don't have it already). For immediate solutions, using If you'd like to discuss with the team further please add the Long term, I like the idea of a flag to check if layout grid is loaded. We'll have to see what additional components rely heavily on layout grid. |
This comment was marked as outdated.
This comment was marked as outdated.
Reopened based on the discussion in Dev sync - Release check-in 🔒 (only GSA emails). |
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.
Thanks for re-opening this. Tested in DigitalGov and locally. No issues found.
I've modified the PR description to improve clarity on what changed by adding a code example.
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.
Looking good! Just one small note about aligning .grid-gap
output with the current CSS. Not sure if it is necessary but wanted to flag for consideration.
- Confirm no visual regressions with default view
- Confirm that various
desktop
grid classes work as expected - Confirm that various
mobile-lg
grid classes work as expected - Confirm that various
tablet
grid classes work as expected
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.
Looks good to me!
Summary
Fixed a bug that caused some grid utility classes to be ignored when used inside usa-footer. Resolves style specificity issues between
usa-footer
andusa-grid-layout
. This resolves visual regressions potentially caused by #5289.Breaking change
This is not a breaking change.
Related issue
Closes #5676
Related pull requests
Changes implemented in #5289
Preview link
Footer →
Demo repo →
Demo footer →
Problem statement
Layout grid styles defined in footer have higher specificity than other layout-grid styles. As a result, updated layout grid utility classes in footer markup do not affect layout as expected.
Solution
Tip
The files changed may look confusing, but it simply moves the styles above the
.footer{}
declaration instead of nesting them.Move layout grid classes above
.footer
class.Example
uswds/packages/usa-footer/src/styles/_usa-footer.scss
Lines 25 to 45 in 9fe48ce
Testing and review
The demo repo below showcases how footer-defined grid styles have specificity over standard grid classes when both are imported to a project.
3.7.1
footer
andgrid-layout
<li>
style changesnpm install @uswds/uswds "https://github.com/uswds/uswds/tree/cm-footer-grid-hotfix" --save
Testing checklist
_usa-footer.scss
$theme-layout-grid-use-important: true
is not required for desired layout-grid stylesFurther consideration
I considered investigating a
sass:meta
test to check for the inclusion ofgrid-layout
and nest the footer grid classes within that but figured this would be enough for a hotfix/mvp.Alternatively, we could investigate using a theme setting to enable/disable these styles. I opt for a logic test (if possible) so users are not required to take an extra step other than importing
grid-layout