[csswg-drafts] [css-inline-3] It’s super easy for overflow collisions to occur when using `leading-trim` (#8474)

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

== [css-inline-3] It’s super easy for overflow collisions to occur when using `leading-trim` ==
[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.]

Like before, this also comes from the fact that the block container is trimmed to the metrics of the root inline box, which isn’t stretchy like how the line box is stretchy.

Consider content like:
```HTML
<div style="leading-trim: start">a<span style="font-size: 5000%">b</span>c</div>
```
The top of that `b` is going to stick way up above the block container, and it’s going to intersect with and cover up the previous paragraph.

Also, consider content like:
```HTML
<div style="leading-trim: start">a<img src="...">c</div>
```
A tall image will overlap the previous paragraph the same way.

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 when fonts with specific fallback metrics are selected seems like a footgun for portability.

One potential mitigation would be to trim the block container to the metrics of the tallest inline box on the first line (or deepest inline box on the last line). This will work for the first example above, but intentionally won’t work for the second example above. But maybe that’s a good thing! `leading-trim` is a text-focused property, so maybe we intentionally don’t want it to be affected by images or replaced content!

An alternative potential mitigation is similar to above, but include images and replaced content in the calculation too. Make the spec actually pick locations for where all these metrics lie on replaced content. (IIRC the spec already does something similar to this for baseline alignment). E.g. the cap height of an image would just be defined to be the top of the image. So, a tall image might end up being the inline box whose metrics the block container gets trimmed to.



Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8474 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:06 UTC