[css21][css-inline] Height of an inline-level box with line-height:normal using primary and fallback fonts

[frivoal]

This is part of the #1796 series. Read that issue for context

All browsers (Safari, Chrome, FF, Edge) agree, that the height of an inline-box with line-height:normal and which uses characters from the primary and fallback fonts goes from the top of the highest to the bottom of the lowest. In other words, the result is the same as the height of a line box containing one inline box for each of the font used.

Test source
Ref source
Live test
Live ref

Given that we have interop, we should specify that.

[frivoal]

This means that the following description of the normal value, found in 2.1, is wrong:

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 . We recommend a used value for 'normal' between 1.0 to 1.2. The computed value is 'normal'.

Instead, the 1st and 2nd paragraphs of 10.8.1 Leading and half-leading, plus a sentence like the following, would be a good description of the line-height:normal behavior.

When the line-height property is normal, the height of the inline box encloses all glyphs, going from the highest A to the deepest D.

[frivoal]

The following sentence in 2.1 is also wrong and should be removed, since for line-height:normal, browsers work with a combination of all fonts, rather than picking just one:

When an element contains text that is rendered in more than one font, user agents may determine the 'normal' 'line-height' value according to the largest font size.

[tomhodgins]

The line-height: normal as defined in the spec is not good enough. Every browser has a slightly different take on what it should be, and different fonts seem to affect it. I dug around for my testing material and I can't find it - but we have a feature in EQCSS that lets you apply styles based on min-lines and max-lines of text visible inside an element, a calculation which involves knowing the computed height, subtracting border and padding, then dividing the remaining space by (font-size * line-height) which works great…as long as the line-height is specified.

I had the hardest time boiling line-height: normal down to a cross-browser value we could use so I had to fudge it. Based on testing in different browsers, fonts, and sizes, the number that I came up with for a real world average was 1.125. I remember seeing lower than that, and as high as 1.6.

Here's the relevant snippet from the plugin:

if (element_line_height === 'normal') {

  var element_font_size = parseInt(computed_style.getPropertyValue('font-size'));

  element_line_height = element_font_size * 1.125;

} else {

Hopefully we can lock down what line-height: normal ought to be, or at least provide a better way to measure what it actually has turned out to be as-rendered.

[frivoal]

@tomhodgins Yes, inconsistencies in line height measurements are a pain. Attempting to lock down what line-height: normal and other values of line-height out to mean is what this #1796 series is all about.

If you find that any of the tests that I wrote is wrong or overlooking something, or that the conclusions I drew from them are problematic somehow, feedback would be greatly appreciated.

[dbaron]

One issue here is that the A and D here are potentially different from everything else because they may include external leading metrics from the fonts, so I think they may need to be different constants.

[dbaron]

(Oh, except in Gecko -- that's the really weird behavior I was trying to remember -- considers the external leading metric only from the first font, and not from other fonts that happen to be used in the text!)

[frivoal]

@dbaron I've opened #1992 to look into that exception. In the meanwhile, I'll make the edits in a way that allow (but does not require) different font metrics being used.