[css-inline-3] leading-trim 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 leading-trim is supplied alone, it 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 larger than the root inline box’s metrics.

The spec says:

For block containers: trim the block-start side of the first formatted line to the corresponding text-edge metric of its root inline box.

The root inline box is not stretchy the way the line box is stretchy, so trimming to metrics of the root inline box - even if it’s the leading metric - won’t take into account tall inline boxes on the first line or deep inline boxes on the last line.

However, most of the use cases for this property is longform content: books, articles, etc. In this kind of content, the first line usually won’t have any tall items on it (and vice-versa with the last line). So the property will usually not have any effect. It will have an effect in the corner case when such a tall object exists on the first/last line, though.

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.

A potential mitigation is to make the leading-trim property take the metrics values themselves, rather than start | end | both. This way, specifying leading-trim will always lead to a behavior change, and it would be obvious to an author playing around with it what the property does.

[dbaron]

When I read the spec, I was surprised that the "(treating leading as text)" parenthetical was only present for inline boxes and not for block boxes. Having that rule apply to block boxes as well would, I think, make the property have an effect in more cases, and matches at least my expectations a bit more.

[fantasai]

@dbaron I agree, and one of the benefits of splitting text-edge into a property that hooks into leading-trim and a property that manages inline box sizing, as was proposed by WebKit's Alan (but afaict never actually filed as requested???) is that this could be made more explicit.

[litherum]

start
...

For inline boxes: trims the block-end side of the box ...

I assume this is a typo, and should say "trims to the block-start side of the box"?

[litherum]

We think #8829 supersedes this issue.