Re: [csswg-drafts] [css-rhythm-1] Avoiding accidental double spacing

I just created three fonts to test what the different browsers do.

tl;dr: All browsers agree about how line-height works (both the magical `normal` as well as `<number>`).

The test fonts are Ahem, Ahem with a super large ascent, and Ahem with a super large descent. I also selectively removed support for specific characters from each font such that every fallback situation could be tested.

```
"X" means "present in font"
"_" means "not present in font"
             A B C D E F G H
            ————————————————
AhemSparse | X _ X X _ X _ _
AhemTall   | X _ X _ X _ X _
AhemDeep   | X _ _ X X _ _ X
```

The HTML file has a few tests which set line-height normal and line-height <number> on some text. I wanted to compare the case of `font-family: AhemSparse, AhemTall` and `font-family: AhemTall, AhemDeep`. All browsers agree on the rendering of all of these tests.

Therefore, we can say:
`line-height: normal` means: "For every line inependently: Union all the ascents. Then union all the descents. Add them together. This is your line-height for that specific line. Place the baseline at a distance down equal to the union of the ascents."
`line-height: <number>` means: "Ignore secondary fonts. Consider the primary font's ascent and its descent. Add these together, and subtract that from the computed value of line-height. This is the extra vertical space required. Place the baseline at a distance down of half this extra vertical space plus the ascent of the font. Now that you have the baseline position, place the rest of the glyphs on that same baseline."

This behavior is contrary to what both @dbaron and I described at the Tokyo F2F.

The behavior gets more complicated when you add inline elements to the line. In this situation, you compute the baseline calculation described above independently for each element on the line. The lowest baseline wins; place everything on that baseline.

This element-based behavior is what @dbaron was describing at the F2F, except he erroneously applied it to fallback fonts, when in fact it only applies to elements. This element-based application causes the bad behavior of increased effective line-heights because of mismatched (primary) font metrics in different spans on the line.

Test fonts attached: [lineheight.zip](https://github.com/w3c/csswg-drafts/files/976958/lineheight.zip) (Beware; these are just for testing, and are not production-ready; please don't use them anywhere real!)

-- 
GitHub Notification of comment by litherum
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/938#issuecomment-299248553 using your GitHub account

Received on Thursday, 4 May 2017 17:07:36 UTC