[csswg-drafts] [css-inline-3] `leading-trim` only has an effect by itself in corner cases (#8473)

litherum has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-inline-3] `leading-trim` only has an effect by itself in corner cases ==
[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](http://w3c.github.io/csswg-drafts/css-inline-3/#valdef-leading-trim-start):
> 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.



Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8473 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 20 February 2023 02:57:04 UTC