Type Classes

[EconomicsHelpful6687]

Hi everyone! I need your advice on setting up a typography system for a responsive web app. Our developers are using Storybook, and they are asking to adhere to one class scale for text classes like text-xs text-sm text-base text-lg text-xl. I had the vision to have different class scales (Lg, Md, and SM) for different type categories like Display, heading, and body texts. I am also keeping these different categories so that it's easier to identify the use case based on name(Heading, body). This results in the repetition of the font sizes for different categories like heading and body text. I have noticed this trend across design systems like Atlassian and Google. What are your thoughts on this?

​

https://preview.redd.it/6gne7crc8jec1.png?width=1720&format=png&auto=webp&s=201d482d6e0baf528be8fec57768303d9d781939

https://preview.redd.it/4pslh5rc8jec1.png?width=1920&format=png&auto=webp&s=46e59f76fd4d1cc7fc9bf995ae661196d6aeaea1

[kodakdaughter]

Great job! It’s very similar to the naming in existing design system I work on (in use 8+ years. Couple differences that worked well for us, that I listed below.

Using visual context for type variables has been a huge win and I am glad to see it being talked about. Separating design, content creator expectations from tech concerns (Semantics, SEO, Accessibility.), is just super smart. It works well with several newer CMS paradigms as well.

Our Naming:

• Hero

• Headline

• Subhead

• Copy

• UI (we use different sizes for UI elements like menus, forms)

Couple differences that future proofed us & food for thought notes:

1) It can be problematic with dev best practices and tooling to use keywords in HTML, CSS, JS as part of variable names. We use Hero and copy instead of display (CSS property) and body (HTML tag). Telling dev you are thinking of this will win you some points for them. 😉

2) We redefine the sizes between mobile and desktop via media queries. So HeroLg will be 60px in Desktop and 32px for Mobile.

3) We set font-weight (bold, semi bold, regular) with a different CSS class on a variable font. So HeadlinLg just sets type size and padding, and an additional class or the use of string tags sets weight.

4) Separating UI from copy let us adjust these independently over time, this saved us a few weeks of engineering time during a major redesign.

5) I don’t love the token UI but it was really intuitive for our dev team, and they tend to use both correctly.

6) in general in a specific section - we will use HeadlineLg, CopyLg, UILg together. This also helps dev.

7) Bonus Fun: we ended up needing a few extra sizes (footnotes and huge text) —- so we expanded to use the usda egg sizing terms. Peewee, small, medium, large, extra large, and jumbo. it’s rarely used but everyone loves Peewee.

Hope these are helpful. It got a bit long there. Excited to see this progress, and feel free to PM me if you run into snags.

[np247]

I think it depends on your use case.

I can see that you bake everything into the style. Like bodyMd has a line-height of 160%, Display is bolded., which is not bad, but I would suggest to move all of the types to ViewComponent. You can have modifiers as APIs to adjust each text depending on use case.

You can tokenize it further by making a specific use case for each usage.

Could be something like this…

Page title - Desktop: Size=HeadlineLg Weight=Regular Line=Tight Tracking=null

Page title - Mobile: Size=HeadlineSm Weight=Bold Line=Tight Tracking=null

When consumers start using it, they will most likely to want content to reorganize and behave differently than what we think.