Design Tokens

[coreyvickery]

Use this discussion to chat about Design Tokens.

[coreyvickery]

A discussion about the upcoming Design Tokens page on ux.redhat.com.

Corey Vickery
@Benny Powers I made a very rough pass at putting together a Design Tokens page on ux.redhat.com using the information from the spreadsheet.

https://xd.adobe.com/view/96c3f58e-cd03-46af-861f-225224554ecc-c390/

Benny Powers
this looks good i'd like to make the dev server in tokens repo implement this design, and we could pull in the template to system repo to display on ux-dot

Mark Caron
I think it'd be helpful to be redundant in sections like Border. Scrolling too quickly might leave one reading Color and not know the context is Border color

I like the overall look and layout though

Mark Caron
Another thought would be to make the Length bars slightly more obvious with caps on each end, like:

|————————|

[bennypowers]

Since this was opened, Red Hat Design Tokens first release is out.

You can view them at https://red-hat-design-tokens.netlify.app/

[heyMP]

Should we be using rem in token values?

Why the heck would we not use rem values?

Great question! Normally I would say that we should absolutely use rem values. The problem is that RHDC sets the root font-size to 62.5%. Which means that all of our token values would be messed up. There was a long history of why this value was/is set that @markcaron and others might be able to illuminate for us. But as it stands, I don't think that font-size: 62.5% can easily be removed.

Alternatives

ems

pros: Using ems in combination of setting font-size: initial; on a parent container, we could retain the ability for our components to comply with a11y browser settings. Take rh-footer as an example:

<rh-footer>  <--- font-size: initial;
   <rh-global-footer> <--- font-size: 0.75em;
     <p slot="secondary">Footer text here...</p> <--- font-size: inherit

cons: ems can get you into very sticky situations when nesting them. Makes it more difficult for the devs to account for nesting.

px

pros: Using px values ensure that that the values in the design system are reflected 1:1 in the components and websites. It ignores the wacky font-size settings that can occur for site to site.

cons: It doesn't allow user a11y settings to control default font-sizes.

Required root font-sizes

We could say that "to use our design system components you have to have a sane root font-size setting.

pros: It's the best long term solution. It allows us to stick with rem in our tokens.

cons: Can be difficult for our old monolithic sites to make this change. Lot's of legacy code that relies on that root font-size.

Summary

All of these solutions are... 🤢

[zeroedin]

cons: ems can get you into very sticky situations when nesting them. Makes it more difficult for the devs to account for nesting.

How much nesting do you think will actually happen in components? Dev eXp at that point is probably the least of our worries, I think it's probably the small price for the A11y win.

I think the other con (for dev exp anyways) might be that if you are using ems for fonts and allow the user preference (which I am doing in secondary-nav as well), you should go one step deeper and use them for breakpoints too. Doing so makes sure the component is breaking scaled on those font-size adjustments by the user.

This ensures design but could result in a mobile view at larger screen sizes for people with adjusted font sizes larger than the default (16px). Sometimes this might not be ideal but in my naive opinion, not the worst, the mobile experience should be ideally as good as the desktop. But I wonder what @kelsS thinks about this as well. Do we have any user testing on this?

[heyMP]

Here is something that I think em will make difficult with design tokens.

<rh-footer>  <--- { font-size: initial; }
  #shadowroot
   <rh-global-footer> <--- ::slotted(*) { font-size: var(--rh-font-size-body-text-xs, 0.75em); } // expected to be 12px
     #shadowroot
     <rh-footer-copyright slotted="secondary"> <--- { font-size: var(--rh-font-size-body-text-md, 1em); } // expected to be 16px but calculates to 12px

[heyMP]

Where if we had rems without overriding root font size it would work fine.

<rh-footer>
  #shadowroot
   <rh-global-footer> <--- ::slotted(*) { font-size: var(--rh-font-size-body-text-xs, 0.75rem); } // expected to be 12px
     #shadowroot
     <rh-footer-copyright slotted="secondary"> <--- { font-size: var(--rh-font-size-body-text-md, 1rem); } // expected to be 16px

[coreyvickery]

@bennypowers @heyMP Moving our discussion to here.

Below is the unified footer demo with the new design token for font size. I am guessing the font size is rendering smaller in the demo vs. my XD spec because of the conversation above.

Did you all settle on a fix for this weirdness yet?

[bennypowers]

WRT the changes to rh-footer specifically, let's continue in pr #505, so that we don't lose track of necessary changes.

[bennypowers]

9931c35 sets the site-wide font size base to 16px, which should pave a smoother path for design reviews assuming rems

[jvprh]

@coreyvickery @marionnegp @bennypowers @ryanaltvater @zhawkins

We are working toward building an updated library of utility classes for two use cases: 

The library will be used by Studio Developers to build the custom designs Studio Designers bring to the table, which, quoting Aaron Williamson, “definitely find use cases where off-standard sizing is necessary. We should generally lean on the standards but part of the purpose of the studio team is to break—or suggest necessary enhancement to—standards.” This is an update to what we’ve done for the last X years with webdms.

The library will also be used in our enhancements to Layout Builder for FTS:Next Generation, where users can choose options for padding-top, padding-bottom, bg colors, etc, as well as build both standard and flexible (flexbox-based) layouts.

Our interest is in having consistency in both use cases, as well as making sure that this library starts from the ground up being in sync with the design system by incorporating design tokens to help determine values. However, we are finding some issues for values that fit “in between” spacer as they’re currently defined. An example would be if a design called for a 40px spacer, there isn’t a token for that value, though it is an increment of the 8px base. 

Some additional feedback is that the naming convention for spacers as they’re currently defined requires some “cognitive overhead,” so to speak. Where a 4x value equal to 32px is simple mental math, the values as they’re currently mapped require memorization of the t-shirt sizes.

Our hope is for consistency that accounts for the guardrails of the design system and the flexibility needed by Studio designers & others, without having to create code that diverges from rhds/tokens while they are still in their early stages.

[heyMP]

Just throwing this out there for weird ideas. What if Layout Builder had the following options for selecting padding.

1. Dropdown with all of the tokens related to spacing. (rh-space-sm, rh-space-md, rh-space-lg)
2. Custom values that don't appear in the dropdown select allowing you to opt-out of the design system spacing.
   B) Maybe a "multiplier" value that would be applied to a CSS calc() function:

• User selects "rh-space-lg"
• User enters a multiplier of "1.5"
• Inline style would be "padding: calc(var(--rh-space-lg) * 1.5)"

[zeroedin]

I was thinking something similar combining spacers using calc. calc(var(--rh-space-xs) + var(--rh-space-lg)) = 20;

[marionnegp]

@zeroedin, that would mimic how we sometimes combine spacers in our XD kits.

[coreyvickery]

@markcaron Do we need to create a separate meeting about this?

[coreyvickery]

@bennypowers Seems like we might need to re-evaluate how we name some tokens? Perhaps a meeting is necessary to get everyone on the same page.

[bennypowers]

care to elaborate?

[heyMP]

Some of these tokens are out in the wild with footer being deployed. Not saying those can't or shouldn't be changed, but something to think about.

[marionnegp]

I think we should revisit --rh-color-border-danger-on-light and --rh-color-border-danger-on-dark tokens because they're currently using our light and dark brand colors. Maybe --rh-color-border-brand-on-light and --rh-color-border-brand-on-dark would work? We use #e00 and #FF442B as border colors in rh-accordion and jump links, so I'm not sure if we'd want to change the token value.

We might still need need a danger border color for other components. rh-alert is using #C9190B, which isn't mapped to a color token.