[css-inline] Can't specify line gaps

[fantasai]

The syntax for line heights is line-height: <length> | <number> | <percentage> | normal where <percentage> is computed against 1em, and <number> represents a value that computes to itself and resolves against the font-size.

It's not possible to specify line-heights by the amount of gap. We might want to be able to do that. In theory it would be line-height: calc(1 + 2px), but that's not valid.

[frivoal]

I support doing something along these lines. One combination that I think is particularly important is normal + <length>. Currently, authors can either:

• use line-height: normal, and benefit from the built-in robustness that this value offers by taking font metrics into account, and avoid overlap even in unexpected situations (which can easily arise due to font fallback and in particular in i18n situations). The downside is that the line sizing you get while doing that is often smaller than what good typography would call for.
• use an explicit (i.e. not normal) line size, and get a typographically desirable line size for their designated primary font, at the expense of losing the font-metrics based robustness.

Here are a few ideas that might address this:

1. allow calc in line-height, so that people can do line-height: calc(1 + 2px) as you said, as well as line-height: calc(normal + 2px)
2. Introduce a new line-gap: <length> property that gets added to the line-height (inherited, initial value 0)
3. change the grammar of line-height from normal | <number> | <length-percentage> to normal | <number> | <length-percentage> <length>? with the second value representing the line gap
4. combine 2 and 3 by having line-gap: <length> be a longhand of line-height: normal | <number> | <length-percentage> <length>? (we'd need to find a name for the other longhand)

I think I like option 3 (or 4) best.

[frivoal]

For the use case I am concerned about, another approach could be having a min-line-height property (inherited, initial value 0). With one of line-height or min-line-height set to normal, and the other set to a typographically desirable line size for the designated primary font, an author would get the size they want most of the time, unless some taller font gets loaded, in which case we'd increase the effective line height to make room it. (note: this too could either be an independent property or a second value / longhand).

For this use case, I think it might be better that what I said in the previous comment, as you still have the robustness factor, but have more predicable line heights than by adding some known value to the unknown size yielded by normal.

That wouldn't let you do the equivalent of line-height: calc(1 + 2px), but I'm not 100% sure what the use case for that one is.

[faceless2]

Another option is to allow the extraction of the metric from the font directly, along with a few others that have been requested: see https://github.com/w3c/csswg-drafts/issues/4780. Then do something like line-height: calc(1em + 2 * font-metric(--line-gap)) (syntax TBD)

[Crissov]

In many (inline) cases, line-height: calc(1em + 2px) would end up in the same result (and the spec should explain better when it does not). Intuitively, line-height: calc((1em + 2px) / 1em); would result in the respective <number> and line-height: calc((1em + 2px) / 1em * 100%); in the respective <percentage>.

[faceless2]

I think what @fantasai is getting at here is being able to add 2px to whatever the normal line-height is, not 2px to the current font size. The results will almost certainly not be the same!

[Loirooriol]

1462 has good arguments against line-height: calc(1 + 2px).

I agree with @tabatkins that adding new <length> units that are not absolutized into pixels seems a better solution than mixing numbers and lengths.

[tabatkins]

Yeah, it's strictly impossible to do calc(1 + 2px); if we want that functionality, we'll have to add an actual unit that means the same thing as the number.