[css-rhythm-1] Avoiding accidental double spacing

[frivoal]

The spec for https://drafts.csswg.org/css-rhythm/#line-height-step says that

It is usually recommended to set the line-height lower than the step unit. The used line height can increase due to several factors such as the use of vertical-align or font fallback.

The initial value of line-height is normal which is defined like this:

normal
Tells user agents to set the used value to a "reasonable" value based on the font of the element. The value has the same meaning as <number>. We recommend a used value for 'normal' between 1.0 to 1.2. The computed value is 'normal'.

Actual implementations are know to vary, and in practice the actual numerical value of line-height: normal is unpredictable. Ideally authors will not rely on it and manually set the line-height when they want to use line-height-step, but we should try to be robust when they don't.

If normal in a particular browser on a particular os with a particular font is equivalent to 1.15, and on a different browser/os/font combination, it is equal to 1.25, and an author leaves line-height at the default value, and sets line-height-step to 1.2em, things will look fine in one browser and not in the other, and the author may not know if they do not test in that particular browser/os/font combination.

I think it is quite important to reduce or eliminate this kind of situation, so we should do something.

How about this:

When line line-height-step is not 0, then line-height: normal is treated as line-height: 1 when computing the used value. This would usually be appropriate (and in the odd case where it is not, it is always possible to set a manual value), and would eliminate variation between browsers, making naïve use of line-height-step more robust.

[kojiishi]

I understand the motivation, but I'm not a big fan of adding more automatic magic behaviors.

line-height: normal causing different layout by browsers/platforms are already widely known facts. Most recent reset.css has line-height: 1. Fixing it automatically only when line-height-step is set looks like we're recommending not to to set line-height. We're not, correct?

Also, the problem you state isn't limited to line-height. What if author forgot to set font-size? If the font-size is larger than a test device, it may result in two units, but we can't fix it, correct?

I have a mid preference to let authors to deal with their errors, and minimize the magic behaviors in the platform.

[frivoal]

line-height:normal being a little different depending on the browser is not a major problem when step sizing is not involved, because the differences are subtle. In this case, the differences could be large (some browsers/os/fonts combinations getting double spaced, some other not), and the fix seems easy.

When the problems are obvious and the solutions hard, leaving things up to authors is fine. Here it's not the case.

[fantasai]

If we make behavior dependent on whether or not line-height-step is initial, the initial value needs to be none.

If we want font-based line heights to be possible to use with step-sizing, we need to add a normal keyword (that computes to its absolute length) to line-height step

[kojiishi]

If we want font-based line heights to be possible to use with step-sizing, we need to add a normal keyword (that computes to its absolute length) to line-height step

Can you clarify how author can do:

line-height: normal;
line-height-step: 18px;

that was what I wanted to ask but probably failed, sorry about that.

[kojiishi]

If we make behavior dependent on whether or not line-height-step is initial, the initial value needs to be none.

I'm fine to add none if desired.

[kojiishi]

Added i18n label because this proposal will cause lines to overlap for some scripts.

[kojiishi]

Since I wasn't able to express my points very well in the weekly conf call, let me continue my points here by cc'ing people who spoke at the weekly on 25 Jan, from IRC log:
@astearns @stevezilles @tantek @tabatkins @dbaron @fantasai @dauwhe @litherum @FremyCompany
There were some points what I said didn't seem to be understood correctly, or I didn't understand even by reading IRC log, so appreciate to read through and comment here if any.

line-height: normal doesn't produce a robust layout as discussed, and I agree that a robust layout is one of important principle in CSS, and that line-height: normal is against that.

The purpose of line-height: normal is different; it is designed to avoid line overlaps as much as possible. Making any text readable without unexpected overlaps is also one of important principles in CSS. These two important principles conflict to each other. I think that is why line-height gives a choice to authors, and I think CSS chose the right default because overlapping is worse problem.

What I was trying to say at the weekly was that we need to give the choice to authors regardless rhythmic sizing is used or not, and IIUC this is also what @litherum was trying to say.

I made a multi-script sample text here (credits to @r12a and @aphillips, thank you!) For scripts in this example, I hope you see normal works perfectly in all browsers, but if we were to pick one fixed value, probably "1.8" is a good value. But I saw an example where "1.8" wasn't still tall enough before. Pick "2"? But it's too tall for some other scripts, such as Latin.

Or, maybe, I wonder, from @fantasai's comment above, this point was understood but cases where font metrics-based line height and rhythmic sizing used together was not understood?

If that's the case, I'm quite sure this case is common; author wants a constant rhythm, such as 18pt. The page has CGM that text can be in various scripts. Author wants to prioritize "lines not to overlap" over "possible additional space when falls back to bad fonts occurs," because font fallback is more predictable than CGM text content. In this case, the combination of normal and rhythmic sizing is what the author needs.

If the author uses line-height: normal, Latin lines will fit to one step unit, while Tibetan may fit to two or three step units, but still the rhythm is kept.

...or maybe concerns discussed there was different from either of above, appreciate if someone can explain more if so.

[kojiishi]

Talked with @tabatkins offline, he said he might try to come up with a new proposal, so I look forward to seeing it.

He also said it became clearer after we talked, so I guess I didn't do good job in conf call or comments above. Sorry about that, let me try to simplify the points.

1. I understand the interop problem with line-height: normal.
2. I understand there are cases where rhythmic sizing may make the issue (1) worse.
3. I believe this proposal sacrifices a CSS readability feature for tall scripts.
4. I think this proposal is net negative, given (3) looks more critical than (1) to me.
5. I mildly prefer solving the original issue (1) altogether, not only the worse one (2).

Happy to discuss more if anyone can come up with new proposals, or disagree with me on 3-5.