[css-inline] Define the content area of inline boxes

[nigelmegitt]

As per requirements detailed at w3c/ttml2#150 define the content area of an inline box generated by non-replaced content, particularly in the block progression direction, such that it can be predicted as a length and used in formulae for example to ensure at authoring time that the background painting areas of abutting spans on consecutive lines meet with no gaps. Although it may not be the preferred solution for defining the size of a background area, even the calculation of an appropriate padding value to achieve this presentation cannot be made currently since the size of inline box areas is undefined.

Tangentially related issue regarding line height: #254

Which spec does this issue apply to? I'm actually not sure. When I discussed this at TPAC2016 with @fantasai she told me that this is related to the Inline Layout Module ( https://www.w3.org/TR/css-inline-3/ ) however that does not seem to have any related specification text whereas the Intrinsic and Extrinsic Sizing Module seems more appropriate, specifically https://www.w3.org/TR/css-sizing-3/#max-content-block-size ; however although that defines new keywords for the height property that could be relevant, the height property itself does not apply to non-replaced content, so it may not be the right place to look.

[dbaron]

If you want the ability to make the border-box height of an inline fill the line box, adding a new keyword to height (@fantasai suggests stretch) seems like a reasonable way to go. Then the distinction on non-replaced inlines would just be stretch vs. all other values, whereas on everything else stretch would be treated like auto (or maybe not...).

[fantasai]

We ended up adding a new property to switch into the desired behavior for TTML. however, the title of this issue stands: what exactly normal does is not very well defined atm. :)
#1974

[faceless2]

( EDIT: this is substantially revised in #2228 (comment))

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 "halflinegap". 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 + halflinegap * 2)
5. The content-box of a non-replaced inline element starts at (halflinegap) at the top, with a height of (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
• halflinegap = hhea.lineGap / 2

and IE11 calculates the values as

• ascent = hhea.ascender
• descent = hhea.descender + OS2.sTypoLineGap
• halflinegap = 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 "halflinegap" 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 #254 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".

(quick edit after posting: if something like this approach was taken, maybe consider making inline-sizing inheritable as well)
(edit#2: renamed "linegap" to "halflinegap" to reduce confusion!)
(edit#3: inline content-box height is ascent+descent, not ascent+descent+halfleading)

[faceless2]

Another quick addendum as this doesn't warrant a post on it's own - but as I was just banging on about font metrics for 100 lines, it's relevant to note that the other significant metric extracted from the font is x-height, used for the "ex" unit and middle alignment. This is extracted from "OS2.sxHeight. If it is zero, Firefox, Chrome and Safari all set it to 0.8em - not the 0.5em currently recommended in css-values-4.