[css-inline-3] leading-trim and descendant inlines

[fantasai]

Currently leading-trim only looks at the root inline box's metric. What if there is content on the first/last line that is taller than the root inline? Should that content also be considered?

We might want to add safe/unsafe keywords to leading-trim, to look at the descendants and pick the highest one, or not and just match to the root inline box. (Probably the default should be matching the root inline box, though.)

[kojiishi]

Adding an option looks ok, but I prefer some other keywords as leading-trim is not safe by design, IIUC, no?

[css-meeting-bot]

The CSS Working Group just discussed leading-trim and descendant inlines.

The full IRC log of that discussion

<TabAtkins> Topic: leading-trim and descendant inlines
<astearns> github: https://github.com//issues/3956
<TabAtkins> myles: The definition right now says "when you got your root box, look at the primary font's metrics, subtract some stuff from the top or bottom"
<TabAtkins> myles: But if there are children in the box, that might be the wrong value. There might be a span with a larger font size, that's now sticking out.
<TabAtkins> myles: One way to solve it is look at all the descendants and find a good value.
<TabAtkins> myles: I think my feelings about this are obvious.
<TabAtkins> [the feelings were not obvious; he doesn't like that idea]
<TabAtkins> florian: So one is do the simple, based on root; another is to look at all descendants and use the tallest one.
<TabAtkins> myles: Coule different evidence
<TabAtkins> myles: Issue was originally phrased to sound like fantasai was just thinking thru it
<TabAtkins> myles: Rather than real complaints.
<TabAtkins> myles: That makes me less inclined to solve this with elaborate solution.
<TabAtkins> myles: Next is that, for the use-cases it was designed for, was simple flowing text in paras. Those don't need this.
<TabAtkins> myles: Finally, the "safe" thing sounds hard and slow to spec
<TabAtkins> dbaron: One thought I had that might work is that what you trim is pieces of inlines.
<TabAtkins> dbaron: If leading-trim is set to trim stuff, you trim all the inlines in the first line, and then do the linebox layout from there.
<TabAtkins> florian: You trim the linebox itself tho.
<TabAtkins> dbaron: Right, I'm asking, why not do it this way? Rather than a fancy calculation about the linebox, it's a simple calculation about each inline's contribution to the linebox.
<TabAtkins> dbaron: In the simple case it works the same, but it produces something pretty logical in more interesting cases.
<fantasai> Hi!
<TabAtkins> myles: I think that's similar to line-ehgith on an inline; linebox amalgamates those
<TabAtkins> dbaron: It's not quite similar; you still set it on the block, but you trim on each inline
<TabAtkins> myles: I think that's a mistake ot repeat that model
<TabAtkins> florian: The line isn't just sized by the stuff inside; an empty line still gets trimmed
<TabAtkins> dbaron: Right, that's the root inline box, which can get trimmed.
<TabAtkins> dbaron: I'm not as convinced as myles that that model is a mistake
<TabAtkins> dbaron: I think it makes sense in the world of CSS where th eperson writing stuff doesn't know how the content will render: wrapping, fonts, etc.
<TabAtkins> dbaron: The model we have is better at dealing with unknowns.
<TabAtkins> dbaron: That said, it could have been looking at different pieces of data.
<TabAtkins> dbaron: The idea that that's how we apply *line-height* specifically, probably broken.
<TabAtkins> dbaron: But the idea that we look at what's in the line individually, that seems fine.
<TabAtkins> jfkthame: dbaron's idea would handle superscript and subscripts for free
<TabAtkins> myles: Not for free, yuo still need to iterate things
<TabAtkins> florian: Do we want to try and sketch out dbaron's proposal, and rethink once we have it in detail and some time to think?
<TabAtkins> jfkthame: Would be interesting to consider.
<fantasai> +1
<TabAtkins> jfkthame: I'm not even sure if taking superscripts into account is desirable.
<TabAtkins> dbaron: Partly this is veering into a separate discussion about wnating a better line-height calculation.
<TabAtkins> dbaron: Had a lot of discussion about that
<TabAtkins> dbaron: Buildling a better model, tho, is separate from leading-trim
<TabAtkins> faceless: If goal is nice presentation text, not inconceivable you might be using baseline-shift to mess with position around th eline.
<TabAtkins> astearns: So should we leave the discussion there, and action david to flesh out the proposal?
<fantasai> One consideration could be to split leading-trim into "what I want to trim to" and "whether I am trimming this line", and could use the former metric as a way of measuring whether something leaks outside the root inline's leading boundaries
<TabAtkins> dbaron: You could, tho someone else might get to it faster.
<TabAtkins> dbaron: I'll bug fantasai about it if she could do it first
<fantasai> It would probably also cascade a little more conveniently, as one usually wants to think about which metric once, but whether to trim per element
<TabAtkins> astearns: So let's do that

[frivoal]

Are related, though possibly separate question, is which font metrics to trim to: only that of the first available font, or the tallest/deepest of all the (fallback) fonts actually used.