[css-inline-3] The interaction of text-box-edge with line-height is not predictable by authors

[litherum]

[This is one of a series of issues we're filing about the design feedback of leading-trim and text-box-edge. As far as we know, these properties are unimplemented in any browser, which means now is a good time to give feedback on their overall design. For each of the issues we're filing, we don't have a fully-formed proposal that would solve the problem, but we do have some avenues of potential mitigation in mind, and we're offering these ideas as a starting point for further discussion.]

There’s a threshold, where if the line-height is above that threshold, it is ignored, but if it’s below that threshold, it’s applied.

The spec says:

... giving an effective ascent above the baseline of A′ = A + L/2, and an effective descent of D′ = D + L/2. However, if text-box-edge is not leading and this is not the root inline box, if the half-leading is positive, treat it as zero.

We’re assuming this indicates that, if the half-leading is negative, text-box-edge is disregarded.

However, negative half-leading is pretty common: authors don’t go so far as to make their lines collide, but most fonts are constructed such that the ink doesn’t actually reach all the way up to the top of the ascent for most text. In places where space on the page is tight, it’s fairly common for a CSS author to tighten up the line height more than the line gap metric so the lines are more snug.

An author writing a web page doesn’t know exactly where the ascent and descent metrics of their font lie. They don’t know whether or not their half-leading is positive or not. They just tweak line-height until the lines look good. It will be frustrating to an author to adjust their content’s line height, but their adjustments stop working at some magical value, because some other property (text-box-edge) was specified somewhere else. (Recall that text-box-edge is inherited.)

One potential solution is to make one of the two always win when both are applied to the same element.

Another potential solution is described in #8478.

[fantasai]

I'm not entirely sure I understand your complaint here, but I suspect you're confused about something.

We’re assuming this indicates that, if the half-leading is negative, text-edge is disregarded.

No, see the statement higher up that says

Unless text-edge specifies a different metric to use, A refers to the ascent metric (for the given font at its given size) and D to the descent metric, each adjusted to account for the dominant baseline’s offset from zero.

text-edge is always applied (except on the root inline box). Depending on the desired line-height, you might also apply a negative half-leading, because if you don't, then you can't set the text any tighter than 1em. We don't apply positive half-leading because it's applied by the root inline box, and you don't want each individual line height to apply additional half-leading -- this is one of the major problems with the inline layout model today.

[litherum]

text-box-edge is always applied (except on the root inline box).

Okay, thanks for clarifying. This makes more sense now.

The case we're thinking of is something like this: (Imagine A+D = 14px, but the author doesn't know this, because authors don't know the exact metrics of the fonts they use)

• The author writes span { line-height: 13px } which has an effect, because 13px is less than A+D, so the line-height of their span is tightened up
• The author wants to loosen up the line-height of the span, so they modify it to say span { line-height: 14px } which has an apparent effect, because 14px is exactly equal to A+D
• The author wants to loosen it up even more, so they modify it to say span { line-height: 15px } which does not have an effect, because positive leading is treated as 0
• The author is super confused now, why 13px and 14px work, but 15px doesn't seem to work

[fantasai]

I'm open to other solutions, but the problem is that if you ask for tighter setting, you need to get it, and if every span contributes its A+D (for some value of A+D based on the metrics chosen in text-edge), then you can't set it any tighter than A+D.

The fundamental model we are going for is:

• The author sets their desired line-height (baseline-to-baseline spacing) on the paragraph.
• The author says what qualifies as the "edge" of the text when measuring whether it overflows the line (potentially overlapping other content), and thus what should cause the line to grow if it doesn't fit within the desired line box height.

If they ask for tighter spacing (line-height) than what the font reserves, we somehow need to give it to them by similarly constricting every descendant inline box. There's maybe a better way to do this, but we need to apply the insetting effect of a tighter line spacing to the descendant inlines somehow.

[SebastianZ]

General note: text-edge was renamed to text-box-edge. So the title and the comments should reflect that to avoid any confusion.

The author is super confused now, why 13px and 14px work, but 15px doesn't seem to work

Side note on this: Debugging such issues already causes authors headaches today. Developer tools around inline layout still need to be created. With the introduction of text-box-edge debugging even become worse.

Sebastian