[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

Topic: leading-trim and descendant inlines
github: https://github.com//issues/3956
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"
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.
myles: One way to solve it is look at all the descendants and find a good value.
myles: I think my feelings about this are obvious.
[the feelings were not obvious; he doesn't like that idea]
florian: So one is do the simple, based on root; another is to look at all descendants and use the tallest one.
myles: Coule different evidence
myles: Issue was originally phrased to sound like fantasai was just thinking thru it
myles: Rather than real complaints.
myles: That makes me less inclined to solve this with elaborate solution.
myles: Next is that, for the use-cases it was designed for, was simple flowing text in paras. Those don't need this.
myles: Finally, the "safe" thing sounds hard and slow to spec
dbaron: One thought I had that might work is that what you trim is pieces of inlines.
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.
florian: You trim the linebox itself tho.
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.
dbaron: In the simple case it works the same, but it produces something pretty logical in more interesting cases.
Hi!
myles: I think that's similar to line-ehgith on an inline; linebox amalgamates those
dbaron: It's not quite similar; you still set it on the block, but you trim on each inline
myles: I think that's a mistake ot repeat that model
florian: The line isn't just sized by the stuff inside; an empty line still gets trimmed
dbaron: Right, that's the root inline box, which can get trimmed.
dbaron: I'm not as convinced as myles that that model is a mistake
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.
dbaron: The model we have is better at dealing with unknowns.
dbaron: That said, it could have been looking at different pieces of data.
dbaron: The idea that that's how we apply *line-height* specifically, probably broken.
dbaron: But the idea that we look at what's in the line individually, that seems fine.
jfkthame: dbaron's idea would handle superscript and subscripts for free
myles: Not for free, yuo still need to iterate things
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?
jfkthame: Would be interesting to consider.
+1
jfkthame: I'm not even sure if taking superscripts into account is desirable.
dbaron: Partly this is veering into a separate discussion about wnating a better line-height calculation.
dbaron: Had a lot of discussion about that
dbaron: Buildling a better model, tho, is separate from leading-trim
faceless: If goal is nice presentation text, not inconceivable you might be using baseline-shift to mess with position around th eline.
astearns: So should we leave the discussion there, and action david to flesh out the proposal?
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
dbaron: You could, tho someone else might get to it faster.
dbaron: I'll bug fantasai about it if she could do it first
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
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.