[css21][css-inline] height of the content area of inline level boxes

[frivoal]

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

test 1	test 2	test 3	test 4	test 5
Test source Ref source Live test Live ref	Test source Ref source Live test Live ref	Test source Ref source Live test Live ref	Test source Ref source Live test Live ref	Test source Ref source (mismatch) Live test Live ref (mismatch)

In the general case (see #1798 for a possible exception), all browsers (Edge, Safari, Blink, Firefox) agree that the height of the content area of an inline level box is solely determined based on (font-size adjusted) font metrics of the primary font, and does not depend on either on the line-height property, nor on fallback fonts. This remains true if there are no characters used from the primary font at all.

CSS21's 10.6.1 Inline, non-replaced elements says a number of things, including:

The 'height' property does not apply [to non replaced inlines]. The height of the content area should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font. (The latter would ensure that glyphs with parts above or below the em-box still fall within the content area, but leads to differently sized boxes for different fonts; the former would ensure authors can control background styling relative to the 'line-height', but leads to glyphs painting outside their content area.)

Since all browsers pick the same option ("the later"), we should lift the ambiguity, and specify (in css-inline-3?) that the UA must use the font metrics, not the em box.

and

If more than one font is used (this could happen when glyphs are found in different fonts), the height of the content area is not defined by this specification. However, we suggest that the height is chosen such that the content area is just high enough for either (1) the em-boxes, or (2) the maximum ascenders and descenders, of all the fonts in the element. Note that this may be larger than any of the font sizes involved, depending on the baseline alignment of the fonts.

This should probably be superseded (in css-inline-3?) by something like

if more than one font is used (this could happen when glyphs are found in different fonts), the height of the content area is not affected by the glyphs from the fallback fonts, and only depends on the primary font.

Even once we've done that, there's still some ambiguity as I don't believe there's any clear definition anywhere of EDIT:use we only have non normative statements about which of the font metrics found in the font file the UA is supposed to , but we'll have at least narrowed it down significantly.

[kojiishi]

This is for when line-height: normal, correct? I can't read well from the spec, but hope we're in sync.

(2) the maximum ascenders and descenders, of all the fonts in the element

Blink actually use "ascenders and descenders and leading" of all fonts. I believe Ahem has 0 for the leading metrics, so you won't see the differences in tests using Ahem.

[frivoal]

@kojiishi

This is for when line-height: normal, correct?

Any line-height. My tests do not show any variation in the height of the content area of inlines depending on the line-height property. Did I miss something?

Blink actually use "ascenders and descenders and leading" of all fonts.

By "leading", you mean some metric embedded in the font file, not the kind of leading talked about it https://drafts.csswg.org/css2/visudet.html#leading , right?

If that's the case, it is very possible. I only checked that it dependent on font metrics, (and nothing else), but not which font metrics.

[...] in tests using Ahem.

I am not using Ahem.

[css-meeting-bot]

The Working Group just discussed github issue: none, and agreed to the following resolutions:

• RESOLVED: To define first available font more strictly in the fonts model and leave it undefined in 2.1
• RESOLVED: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font.

The full IRC log of that discussion

<eae> topic: github issue: none
<eae> dbaron: Want to go back to line height normal. In some cases we use different font metrics.
<eae> dbaron: The text in the proposal was very specific about the metric.
<eae> florian: Will update it to be more clear about the specifics and that the font metrics in question isn't defined.
<eae> dbaron: What metrics are used should be looked at separately. Will add comment.
<eae> github issue: https://github.com//issues/1798
<eae> florian: We discussed whether the first font in the fallback list should count as the first available font even if it doens't have a space glyph. We did not specify whether it should also apply to line height.
<eae> florian: Safari, Edge, and FF half the time consideres it even if it doesn't have a space glyph.
<eae> florian: Safari and Chrome does not.
<fremy> q+
<eae> fantasai: The first available font should have a strict consistent definition across specs.
<eae> florian: Is not consistent across implementations.
<Rossen> q?
<eae> florian: Happy to change if implementations are willing to change.
<eae> florian: I don't really care strongly, arguments on both sides.
<eae> florian: Are edge and safari ok with that?
<eae> fremy: I didn't run all of the tests but I think we do the same thing?
<eae> florian: So there are three compat implementations?
<eae> florian: The first available font wording is used in 2.1 just not defined.
<eae> astearns: Might be acceptable to not test the presence of space in 2.1
<eae> florian: Define it in fonts3 and then have that definition apply to all cases where we mention first available font
<eae> Proposed Resolution: To define first available font more strictly in the fonts model and leave it undefined in 2.1
<eae> RESOLVED: To define first available font more strictly in the fonts model and leave it undefined in 2.1
<eae> github issue: none
<eae> florian: All browsers agree that the size of the content area depends on the size of the primary font, even if no characters from the primary font are used.
<eae> florian: The specification doesn't define the behavior, say "may do A or B".
<eae> florian: Should remove "may do A" as no browser does that.
<eae> florian: Suggest we remove suggestion saying that one may do something that nobody does.
<eae> dbaron: Would argue it should be a SHOULD rather than MUST instead of a MAY.
<eae> myles: Content area also depends on the line-gap property
<eae> florian: Just depends on font metrics.
<eae> florian: Spec says "do whatever you want, here are two suggestions". Doesn't mandate a specific metric.
<eae> myles: Shouldn't say ascent or decent, have specific meaning.
<eae> dbaron: I don't think this ones includes line gap, only asc+dsc.
<eae> github issue: https://github.com//issues/1804
<eae> florian: There is a paragraph saying that if more fonts are used the height of the area isn't defined but we suggest... I propose we remove that.
<eae> Rossen: What about overflow?
<eae> florian: People don't do that for background I think.
<eae> Rossen: I'll follow up with a test case.
<dbaron> FYI, I did figure out the crazy Gecko behavior I was trying to remember: https://github.com//issues/1802#issuecomment-342349505
<eae> astearns: Let's continue making tests given the number of questions raised.
<eae> fantasai: This is about where the backgorund is painted for inline elements, very specifically about backgrounds.
<eae> Rossen: I might be miss-reading the issue.
<myles> dauwhe: don't worry, computers are fast
<eae> fantasai: The question is how tall is the background painted behind the text, can't set overflow on that element. Has to be set on containing block.
<eae> florian: I'm not an editor for any of these specs, there will be pull requests not in spec.
<eae> florian: Would like to move forward.
<eae> Proposed resolution: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font.
<eae> RESOLVED: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font.
<eae> </day>