Re: [csswg-drafts] [css-inline] Define the content area of inline boxes

I've been doing some work on this, with a goal of tightly define the value of "line-height: normal" and the behaviour of "inline-sizing: normal". The latter refers to CSS2 10.6.1 which recommends:
> 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.

So I rolled some tests to see how the various browsers currently implement this.

### Current Behaviour


Given the above diagram, the three values we are defining are:

1. The distance from the top of the line box to the top of the inline box - we will call this "linegap". It's always the same gap at the bottom of the linebox.
2. The distance from the top of the inline box to the alphabetic baseline - we will call this "ascent"
3. The distance from the alphabetic baseline to the bottom of the inline box - we will call this "descent"

Other values that are derived from these include:

4. The value of "line-height: normal" is the sum of (ascent + descent + linegap * 2)
5. The content-box of a non-replaced inline element starts at (linegap) at the top, with a height of (linegap + ascent + descent)

Assuming the font used is an OpenType font containing the "hhea" and "OS/2" tables (in 2018, that's pretty much all of them), then we found Firefox, Chrome and Safari all calculate the values like this:
* ascent = hhea.ascender
* descent = hhea.descender
* linegap = hhea.lineGap / 2

and IE11 calculates the values as
* ascent = hhea.ascender
* descent = hhea.descender + OS2.sTypoLineGap
* linegap = 0

This applies when the font is loaded from the OS, or referenced explicitly via a @font-face rule.

There also appears to be an an additional test in Firefox, Chrome and Safari when "hhea.lineGap" is zero. This is the case with the default Serif font on OS X, for example, which evaluates to /System/Library/Fonts/Times.ttc on macOS 10.3 and which is how I found myself digging into this issue. It's also why I didn't test this behaviour under IE11. I've only tested with the one font so there may be more to it, but what I found was:

* Firefox sets "linegap" to 0.1em. This gives a "normal" line-height of 1.2em and ensure an inline content-box **does not** extend to the edge of the line-box.

* Safari / Chrome adds 0.075em to both "ascent" and "descent". This gives a "normal" line-height of 1.15em and ensures that the inline-box **does** extend to the edge of the line-box.

### Possible Future Direction

It's clear there has always been an intention to define this behaviour in CSS (see and #1974).

At the very least, perhaps some of this could be appended as a non-normative footnote to the spec?

Or, if there was a desire to expand this property to defined the behaviour described here, then purely to get the ball rolling: given the behaviour between Safari/Chrome and Firefox differs only when the linegap is zero I would suggest modifying the inline-sizing property definition to something like:

 `inline-sizing: normal | stretch [linegap | ascent]*`

where "linegap" or "ascent" indicate where repairs to the font-metrics are to be made; Firefox's behaviour is effectively "normal linegap" and Chrome/Safari are "normal ascent".

GitHub Notification of comment by faceless2
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 28 August 2018 15:28:05 UTC