Change font-size and possibly margin and padding declarations from px to rem values

[danbivins]

Background

Currently the typography is set to px, ie:
$base-font-size: 16px !default;

View this here: https://github.com/CMSgov/design-system/blob/master/packages/design-system/src/styles/settings/variables/_type.scss

This causes problems for users such as those who set their preferred font sizes in-browser. By using px values vs. rems we override the user's preferred styling. This means we may be limiting the user being able to increase the text as needed.

Proposed change

Use rem values instead of px for typography and possibly margin/padding. Is it feasible to also change the spacing settings to be rem-specific? Or is there some unforeseen issue I'm unaware of.

[davidakennedy]

I'd love to see this change too. It makes the entire design system more inclusive and resilient.

The support for rems is good. Plus if we were concerned about compatibility in older browsers, we could write a Sass function to output a fallback, or write a simple one with @supports.

[line47]

I think this could be part of our work to align closer with the USWDS which uses Rems for their design tokens https://designsystem.digital.gov/design-tokens/typesetting/font-size/

[pwolfert]

This has been talked about on and off over the past few years. It's still on the table for discussion. I think the two main issues with implementing it right now are 1) the scope of the breaking change and 2) priorities for development. I think at a future date when we have more bandwidth for this kind of work, we should really consider this.

[zarahzachz]

To point 1, scope may be hard to measure if consuming teams have a CSS reset or internal style that sets the base font size to something like 10px or 62.5% (pretty common font-sizing rules afaik).

By implementing relative sizing (which I'm 100% onboard for) these teams will undoubtedly see some zany layout changes, so this change should be communicated very clearly to avoid that.

[cheapwebmonkey]

While I hear and understand the concern for breaking changes, the longer this sits, the more tech debt is accrued, and the more themes are built without relative sizing, which has the potential to introduce a11y issues regarding how fonts scale on a site, which in turn, affects how and if folks can access content

[pwolfert]

We are currently working to align our existing child design systems more closely with the core design system and remove much of the additional CSS that customizes it. When we are fully utilizing our new design token system in our design system, we'll be in a better place to tackle projects like this for all themes at once.

[maggiewachs]

Hi all! I'm an accessibility engineer working on several websites for the Centers for Medicare & Medicaid Services. I noticed this discussion has grown quiet -- any updates?

[mgifford]

DigitalGov recommends avoiding use:

Avoid Absolute Dimensions and Positions in CSS directives
Issue - Pixel and absolute dimensions and positions in CSS directives should be avoided, as they may not allow the browser to adapt content to fit the display or render correctly on all device types. However, there are exceptions to this rule. For example, if you want images to be tailored to fit a particular display it makes more sense to specify the dimension in pixels. In addition, pixel measures may be appropriate for margins, borders, and padding.

Solution – Use relative measures such as em, ex, bolder, larger, and thick where possible. For example, when specifying font, use font-size: 1.5em instead of font-size: 12px.

References: Fixit - Measures

[pwolfert]

Hi @maggiewachs and @mgifford, this change was actually part of our v7 release 🎉

We're not completely finished with all the font updates we want to make, but we've switched from px to rem.