Why I’m excited about font-size-adjust

Hey, yeah, I'm Chris, and these are some very quick his gathered thoughts on why I'm excited about font size adjust.

So the way that we define font sizes currently doesn't really match up with, I think how most people would intuitively like the, the mental model most people have.

So these are two type faces, TT norms at the top and sentinel down below. And I've set them both as a hundred pixels.

And like what most people would expect is that that roughly means that the, you know, the a for instance is probably around a hundred pixels, but as you probably know, that isn't the case.

So what you're actually defining when you set a hun the font size to a hundred pixels is the kind of the inbox, the binding box of the, of the glyph.

The problem, the difficulty that that arises is that the size and positioning of the within the inbox is kind of arbitrary based on the font designer.

And so there's no real standardization from typeface to typeface. And so whereas I've got these two typefaces both set to a hundred pixels in actual fact how that translates is the, the the cap height on the top one is 71 pixels.

Cap height below is 66 pixels. The X height is 48 pixels on the top and 45 below. And so when you are working with multiple type faces and have them, well, whether they're side by side or not, there's a real vari there tends to be a real variation between just the optical sizing.

And you can kind of see hopefully here where even in this example, you know, these are sets to the same font size, but they don't look the same size like the, the bottom row looks at a little bit smaller.

And ex height obviously has a large part to play with that. So if we overlay those things, you can kind of see where yeah, the, the sheriff fund sentinel just even set at a hundred pixels is a lot smaller.

If I matched their X height, so in this case TT norms x height on a hundred pixel side that the X height came out at 48 pixels.

So I scaled up Sentinel to match that. And then I only set them side by side. They looked like, you know, if you squinted, you, you would hardly even tell there are different fonts.

The one's got cis, one's got one's without, but it just helps match the type faces so much easier. And so whether that's in content design or in UI design or whatever, when we're needing to work with multiple type faces, being able to match them and define the, the font size, well define the tech size by X height rather than by inbox size.

Tends to give us a sizing that is a lot closer to, I guess, the conceptual model that we would, or the mental model that we tend to have in terms of what we think we're sizing with when we define type size.

And yeah, just to kind of compare the two there, you know, again, it's, it seems subtle, but it, the ramifications to this plays out, you know, across an entire project and tends to, you know, at least make things feel kind of icky and messy and in the worst cases can completely disrupt the flow of, of, of content.

Another example here where I've just grabbed a bunch of random type faces, so the same two at the top and then a bunch of other random ones that I find in Figma.

And again, these are all set on the left hand side as a hundred pixels font size. But when you match their X height, so on the left, they're all kind of all over the place and you'd, you'd think that actually they're all set to be different sizes, but on the left they're all the same size on the right.

I've matched them by X height. And what that means is, you know, this is the actual font size at their each one is set up to align the X height.

And again, you could work with all those side by side. This is a lot more workable and a lot more coherent.

If you had to work with all these different type faces together, it would work a lot better when you're matching them by ex height.

So the specification mentions this being useful for fallbacks and it is but I wanted to talk about a couple of kind of key use cases that just off the top of my mind are where I think this could be valuable.

So first of all is pairing. So like I've just been saying, it's really common to have to work with multiple type faces.

Oh, there's no battery going. It's really common to have to work with multiple type faces to pair a surf for the sound surf and so on.

And right now to do that well requires knowing the, you know, the differences in scale between the two typeface and effectively having two different type scales.

So if you're, if you're using a scale for headings and so on, you can't just use the same numbers for the surface, for the sand surface.

You have to know for each one what this, you know, if you wanted them to work together. And so being able to define the x height would make it a lot easier to optically match the different type, the different, the sand there from the surf and whatever.

And you'd be able to use a single sizing scale and it would just work no matter what fonts you're using.

Second of all, I think it's themeing, so it's a really common thing that is the use case that we're particularly interested in with Nice.

But I think just in general, it's really common to be working with things like bootstrap or teal wind or, or whatever.

It's really common to be working with design systems whereby the system has been designed with a, a particular type face in mind and has been the size and spacing and so on, has all been done around that type face.

And then when it comes to theming that system you swap in another type face, and even though it's just been given the same font size, you know, it can be vastly different.

So it can, it can look quite, you know, it can quite often be a lot smaller or too big or change the flow.

And so what ends up happening is you get something that again, you kind of need to go start from the beginning again.

And because the type is such a foundational element, you have to start from the beginning and figure out the numbers for this new type face and figure out the skills and size for that new type face and go and adjust all your dimensions if you want this to work well, or I was happens.

In most cases you don't do that, but the whole system just never quite, it feels like a, like an ill-fitting coat over the type phase because it wasn't designed for that, the optical sizing of that type phase.

And then thirdly, I think there's an accessibility benefit. It's, you know, seems increasingly common for people with, you know, reading, disability, reading difficulties, dyslexia and so on, to be selecting specific type faces that help them that are more, they find more legible.

But those, it's, it's not gonna be common for those people to realize that just because they swap out the type face that they also need to consider how that type scales and so on.

And so I think the, the expectation that most would have is that, well, if I've put in a more legible type face, therefore, you know, things will be more legible for me when an actual fact, if that typeface is sized a little smaller or has a, has a smaller X height then it won't necessarily work that way.

And you see this with, you know, it's some, you know, legal documents where there's a requirement or it must be set, you know, this contract must be set in nine point texts or something like that, which completely ignores the fact that it's not really the point size or the pixel size on in digital.

It's the tight face in the X height that has much More impact on how, you know, the legibility and how it's optically perceived.

So yeah, I hope that made some sense. Would love to chat further about this or put together more demos or whatever.

Like anything I can do to basically encourage the pars it be to, to make this a reality I think it would make such a difference to be able to define type sizing by the X height rather than by font size, which is typically a per proxy for what we're actually trying to, to do.