Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type scale, revisited #102

Closed
hobbes7878 opened this issue Jul 21, 2023 · 2 comments · Fixed by #99
Closed

Type scale, revisited #102

hobbes7878 opened this issue Jul 21, 2023 · 2 comments · Fixed by #99
Assignees
Labels
discussion Needs talking through

Comments

@hobbes7878
Copy link
Member

hobbes7878 commented Jul 21, 2023

So I've been looking a lot at the proposed type scale for the last couple weeks and comparing it to others' as I'm updating a lot of other parts of the upcoming styles release. Just wanted to re-check a couple alternative ideas to make double sure we're using the best system for us.

Boils down to 2 things:

1. Our token system

Ours consists of basically two levels of tokens: size tokens 1-6 (largest to smallest) and then role tokens like hed, subhed-1, body, note-1, etc.

I think we should consider size tokens that revolve around a base, instead: xs, sm, base, lg, xl, 2xl, etc.

There are a couple major advantages to this for me: For one, I think these tokens are easier to remember and use correctly. I understand base as my paragraph text and smaller and larger variations from that intuitively. Less so, for example, what, size 3 is. The second advantage is more range at the top end of the scale. I think we need to accommodate more sizes of headlines and display text, which is easier for the base-based system when you can keep tacking on XLs. For example, Tailwind goes up to 9xl.

I'd keep the role tokens as is, and that gives us two ways to think about and set font sizes. We'd likely use those role tokens (which include font-weights and line-heights, etc) internally in the components and more likely size tokens in individual projects when making fine adjustments, especially at the high end, which is where I see the most custom CSS written.

2. Responsive sizes

I've been really impressed by fluid type scales and, especially, this tool: https://www.fluid-type-scale.com/calculate

It's especially nice that it handles mobile without an explicit breakpoint. Turns out setting that breakpoint is a fairly messy thing to do using our CSS variable based system in the Theme component while keeping it easily over-writable for clients...

I think we can still keep the harmonic scale as proposed, but instead of one major breakpoint, can let those sizes respond fluidly across viewports.


For open discussion...

@hobbes7878 hobbes7878 added the discussion Needs talking through label Jul 21, 2023
@hobbes7878
Copy link
Member Author

Re: fluid type scale, think it helps to look at an example.

This one I think is fairly close, so I reworked a recent page using it for all the major body copy: https://graphics.thomsonreuters.com/testfiles/2023/FKy4u9avNIL/

@hobbes7878 hobbes7878 mentioned this issue Jul 22, 2023
6 tasks
@hobbes7878 hobbes7878 added this to the New type system milestone Jul 22, 2023
@hobbes7878
Copy link
Member Author

As discussed, will move forward with a single set of font size tokens defined around a base and size fluidly. Text role tokens will stay the same and be composed with those font size tokens.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Needs talking through
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants