Should borders/spacing always be expressed in rems? Should we offer both rem/px?

[zeroedin]

This is an offshoot of the discussion going on on the Design System discussion board: #385

If we allow users to scale the font size in the browser, and in my opinion, we should be. This presents an issue with using rem values for all our space/length tokens.

https://github.com/RedHat-UX/red-hat-design-tokens/blob/main/tokens/border.yml
https://github.com/RedHat-UX/red-hat-design-tokens/blob/main/tokens/length/length.yaml

While rems are great for text and for spacing when you want to scale that space value with the font-size changes. It might not be the best idea to make them the only option.

For example, you might not want to scale borders when text is adjusted by the user. Or you might not want to increase the padding in a button around the text when the font is scaled on smaller screen sizes.

Should we be offering both values? Maybe with a px context modifier?

--rh-border-width-lg: 0.1875rem; /* 3px border width: Example: Expanded Accordion panel */
--rh-border-width-lg-px: 3px;

The --rh-border-width-lg would only be 3px when the user is using the default Medium font setting in their browser, if the user switches to Extra Large that value is then 4.5px; While that doesn't seem like a big switch it is much more dramatic and possibly unwanted when you are dealing with larger spacing values:

 --rh-space-5xl: 5.0rem; /* 80px spacer */
 --rh-space-5xl-px: 80px;

At Extra Large the 5xl spacer is now 120px which might not be what you want at certain screen sizes.

Offering both px and rem values might be the most ideal, allowing implementors to be able to choose what is best for a particular design.

This does come with the caveat of people using the wrong token. A "guideline" would most likely have to be written to offer up best practices.

[bennypowers]

Looping in @heyMP, @coreyvickery, @markcaron, and @dcaryll: this has been discussed in other places (footer revert, footer spacing controls, design tokens discussion). Let's focus discussion here so we can work this out.

[coreyvickery]

@bennypowers I wish I knew the answer here, can design do anything to help guide this discuss along?

[bennypowers]

On the one hand, PFv4 uses rems. OTOH, RHDC sets a root font-size in %, so that's trouble. Is there room in RHDC-land to reconsider that choice?

[coreyvickery]

@bennypowers @heyMP Where are we with working this out? Does this have any effect on font sizes rendering smaller or larger than pixels?

[bennypowers]

#505 solves this

[bennypowers]

A view on this discussion from our colleagues at Clever Cloud

https://github.com/CleverCloud/clever-components/blob/master/docs/adr/adr-0021-from-rem-to-em.md