[css-inline-3] handling the line gap metric

[fantasai]

IIRC, we had an inconsistency among browsers about whether line-height: normal includes the font’s line gap metric or not. It's not clear to me whether we can get interop on this or not, but my suggested definition is:

• it is included for the root inline box
• it is not included for any other inline box

Interested in thoughts from @litherum / @jfkthame ... we can also continue to leave it undefined.

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] handling the line gap metric.

The full IRC log of that discussion

<ntim> scribenick +ntim
<dbaron> Scribe+ ntim
<dbaron> ScribeNick: ntim
<dbaron> s/Scribe+ ntim//
<ntim> fantasai: there are inconsistencies with whether line-break: normal on whether it includes the line gap metric
<dbaron> s/break/height/
<ntim> fantasai: I don't know if we can get interop on it
<ntim> fantasai: but I'd like to get input from implementers
<ntim> fantasai: one thing we can do is to not include the metric except for the root line box
<ntim> myles: does any browser do that?
<ntim> fantasai: no I don't believe so
<ntim> fantasai: but it would reduce problems with the line shifting around
<ntim> dbaron: if the compat space is such that some browsers do it and some browsers don't, then fantasai's proposal seems reasonable if compatible
<ntim> myles: if my memory is correct, we include the gap metric on all line boxes when line height is normal
<dbaron> https://searchfox.org/mozilla-central/rev/b741ddde6c678ca7025858952202d20664491555/layout/generic/ReflowInput.cpp#2719-2734
<miriam> q?
<khush> q+
<miriam> ack khush
<ntim> khush: what other input goes into the font line gap metric?
<fantasai> s/into the font line gap metric/into normal line height besides font line gap metric, and is that consistent between browsers/
<ntim> fantasai: different browsers use different metrics, browsers have different ascent/descent metrics that are not entirely consistent
<myles> q+
<dbaron> https://searchfox.org/mozilla-central/rev/b741ddde6c678ca7025858952202d20664491555/gfx/thebes/gfxFont.cpp
<fantasai> s/browsers have/fonts have/
<ntim> khush: is there any motivation?
<dbaron> s/motivation/motivation if it's still not going to make things interoperable/
<ntim> fantasai: yes because it makes it less bad
<miriam> ack myles
<ntim> myles: Yeah, I'll repeat:
<ntim> myles: I'm scared of changing the look of text on all of the web
<ntim> myles: it's somewhat important, that text on the web looks consistent with native text
<ntim> myles: it's not a deal breaker , but i want to bring up the concern
<nicole_> +1 to myles
<ntim> myles: to make progress, we need an implementer willing to try it
<ntim> myles: not willing to try it though
<astearns> nicole: I can ask, but I am skeptical
<ntim> dbaron: blink / gecko seems to both include the metric
<ntim> dbaron: what implementation doesn't?
<ntim> fantasai: I think one of them doesn't
<ntim> myles: what is the motivation?
<ntim> fantasai: the spec says you may or may not
<ntim> fantasai: if all the browsers do a single thing, we should be able to spec that
<ntim> myles: sounds like the next step is research
<miriam> ack dbaron
<ntim> astearns: a single WPT test and looking at results
<fantasai> s/one of them doesn't/when I was looking into it, one of them didn't; might no longer be true/
<ntim> astearns: could be a tentative test
<dbaron> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/style/computed_style.cc;l=2189;drc=31fb07c05718d671d96c227855bfe97af9e3fb20;bpv=1;bpt=1
<dbaron> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/fonts/simple_font_data.h;l=187;drc=31fb07c05718d671d96c227855bfe97af9e3fb20