[css-inline-3] text-edge only has an effect by itself in corner cases

[litherum]

[This is one of a series of issues we're filing about the design feedback of leading-trim and text-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.]

When supplied alone, text-edge does nothing in the common case. But it can have an effect in certain situations. It is capable of producing a behavior change when supplied alone, when there’s an inline box on the line whose metrics are way larger than the root inline box’s metrics.

The spec says:

The chosen metrics are used as the basis for the layout bounds of the inline box (if it is not the root inline box).

The fact that the root inline box is excluded is the source of the problem. The line box stretches to include the tallest ascender and deepest descender of any line boxes on the line. In standards-mode (as opposed to quirks mode) this includes the metrics of the root inline box. So, if all the non-root inline boxes get smaller, but the root inline box stays the same, that won’t have any effect on the line!

But, what happens if there’s a font fallback? Well, if the used font has smaller metrics than the primary font’s metrics, then, again, there will be no change on the line. If the used font’s metrics are slightly bigger than the primary font’s metrics, then the specified text edge of the inline box won’t exceed the leading bounds of the root inline box, and there won’t be any effect on the line either. You’ll get a behavior change if the used font’s metrics are SO much larger than the primary font’s metrics that the specified text edge of the inline box DOES exceed the leading bounds of the root inline box - at that point, the line box will grow.

The fact that it does nothing in the common case means authors are more likely to sprinkle it around in places where it doesn’t belong. Authors don’t know which fallback fonts are picked by the browser, so having a behavior change occur only when the browser picks a particular fallback font seems like a footgun for portability.

One potential solution is to make text-edge apply to the root inline box too.

An alternative potential solution is to make text-edge always have no behavior change when applied alone, but instead have it just set some internal variable (kind of similar to how currentColor works) which can then be referenced by other properties like leading-trim. The use-case of wanting more rhythmic line positions (which is something that text-edge aspires to do today) could instead be worked into other properties - perhaps the properties in the rhythmic sizing spec, or maybe even the line-height property. These properties would be made to use this internal variable to achieve the use-case.

[fantasai]

One potential solution is to make text-edge apply to the root inline box too.

That would mean that the line-height can never be more than 1em, which makes no sense...

[litherum]

One potential solution is to make text-edge apply to the root inline box too.

That would mean that the line-height can never be more than 1em, which makes no sense...

Why not?

Where does the 1em calculation come from? In most fonts, A + D does not equal 1em.

Maybe you referring to this section in the spec:

However, if text-edge is not leading and this is not the root inline box, if the half-leading is positive, treat it as zero.

We filed #8476 about this section; it doesn't seem to make a lot of sense either :)

[litherum]

Closing.