Hey revisiting this again! The biggest blockers for me still are two things:

1. I have no idea what happens when I change the numbers in the formula (round(max(min(2em - .5rem, 1em + .5rem, 2em / 3 + 1rem), 1em), 2px) — do you have any idea how we can get these to feel like labelled knobs that actually have an intuitive effect? It feels very opaque right now.
2. I'm worried about any potential performance impact of making the browser do all this math on every text element.

What are your thoughts?

Good feedback. I was looking at some alternative approaches, and maybe min(2em - .5rem, 1em + .5rem) can be an interesting option. This approach yields even line heights without needing the round() trick.

The only downside is that it does change more line heights for larger font sizes (although you can still set the --text-*--line-height if you notice this causes issues when upgrading from v3 to v4):

Performance

To be honest, I'm not sure about the performance impact or even the best way to benchmark it. My intuition is that the function simply calculates a number, which likely isn't any more complex than the approach we're using with color-mix() to adjust background opacity.

I also noticed the main titles on the homepage of commit, pocket, salient, spotlight, studio & syntax actually follow the logic of 1em + .5rem (or are close (+-1px) to following it).

What do you think about the simplified line height function?

What if we just use calc(1em + .5rem) for all the line heights and still keep --text-xs--line-height and --text-sm--line-height? This will be:

• easy to understand than the functions mentioned earlier.
• easy for designers to pick a line height when choosing a custom font size like 2.5rem, because it's just +.5rem.

And all the upsides mentioned in the PR description.

If we go that way, it might be worth changing the named leading classes. Right now, they often generate odd numbers or decimals:

If we change them to calc(1em + .25rem), calc(1em + .375rem), calc(1em + .5rem), calc(1em + .625rem) & calc(1em + 1rem) we can force even numbers and "adaptive line heights based on font size".

It can also make designing (or converting a design into code) a little easier since there is now an easy to remember relation between font sizes & line heights:
Thight: font size + 4px
Snug: Font size + 6px
Normal (& default): font size + 8px
Relaxed: font size + 10px
Loose: font size + 16px

This does introduce some breaking changes (just like the v1->v2 upgrade), which can be reverted by using the old config.

@MartijnCuppens Sorry I don't think I was clear enough in my original message — what I'm wondering I guess is if this formula can be written in a way where you could give each number a variable name and it would actually be understandable:

min(2em - .5rem, 1em + .5rem)

What is 2em here? What is 0.5rem? What happens if I change them? Those are the things that I wish we could figure out.

Would be awesome to land on something we feel good about here though because I agree it would be really great to get nice automatic line heights even for arbitrary values.

What is 2em here? What is 0.5rem? What happens if I change them? Those are the things that I wish we could figure out.

Well, this is the hard part about these functions indeed. Changing these values is like changing the coeficient and constant in 2 linear equations. Just to find out what these things are doing, you can calculate the matching point with y = ax + b:

y = 2x - .5   (2em - .5rem)
y = x + .5   (1em + .5rem)
⬇
2x - .5 =  x + .5
⬇
2x - x = .5 + .5
⬇
x = 1 (font size in rem)

y = 1 + .5 = 1.5 (line height in rem)

This means 1rem is the point where the functions are the same (= 1 + .5 = 2*1 - .5 = 1.5), for smaller font sizes 2em - .5rem is used, for larger font sizes 1em + .5rem is used.

What happens when you for example change 2em? Well, you 'll need to recalculate the intersection to get a better idea of what is happening.

These min() functions are just incredibly hard to understand, and replacing the numbers with variables doesn't really help.

That’s why I suggested using just 1em + 0.5rem instead. This simpler formula works well for font sizes ≥1rem, though we’ll still need to override line heights for smaller font sizes.

I'm also unsure about how far we should go with breaking changes to line heights. Do we want to avoid any breaking changes at all costs, or would it be worth it if it significantly simplifies things (and possibly lets us avoid decimals in the named leadings)?

It might be hard to grasp what calc(1em + .5rem) actually looks like, so here's a demo: https://play.tailwindcss.com/eJ1qLd9Vkz

Upper part is the current (v3) state, lower part is calc(1em + .5rem).