You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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...
The text was updated successfully, but these errors were encountered:
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.
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...
The text was updated successfully, but these errors were encountered: