Re: [csswg-drafts] [css-inline-3] leading-trim and descendant inlines (#3956)

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

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3956#issuecomment-578208111 using your GitHub account

Received on Friday, 24 January 2020 16:44:20 UTC