-
Notifications
You must be signed in to change notification settings - Fork 10
How Our Styles Relate to USWDS
The entry file for the styles to be compiled is styles.scss which goes through 3 steps
The file is _uswds-theme.scss
This is were we change USWDS variables from their default values to our preferred values.
These changes effect components across the design system.
💡 We may consider renaming this to something like _USAgov-USWDS-Settings.scss to make it clear that it contains our settings for the design system. Alternatively, we could move it into styles.scss and avoid having an extra file….
Here is a list of all the available settings and their variables:
https://designsystem.digital.gov/documentation/settings/#general-settings
This is not a file in our code. It refers to the USWDS node module.
At this step, the design systems gets compiled with our specified settings.
The file is _uswds-theme-custom-styles.scss
This is where we put “our styles.” All the styles that we add on top of the USWDS.
💡 I would strongly consider renaming this to something like _USAgov.scss to make it clear that it is the main file of “our styles”
We should organize each logical component or category into manageable scss files. (right now there are too many styles in this main file)
All of our styles fall into one of these 3 categories:
Styles that effect normal USWDS markup
- Ask yourself: If someone copy/pastes html directly from the USWDS site, will this style effect it?
- These overrides generally take away the ability to create the original version of that USWDS component/utility.
- Avoid this unless it is necessary for something like accessibility.
Styles that effect USWDS markup when extra class is used
- Consider using existing utility classes instead of writing new CSS if possible
Styles that are unrelated to USWDS
- Think of these as “USAGov Components”
- Consider setting variables at the top of each component’s scss file for values that are reused within the component
- Try to use USWDS Tokens for consistency