[css-inline-3] Rethinking line-sizing and leading-trim

[fantasai]

I wanted to follow up on some thoughts:

• dbaron's musings in A Coruña
• Issues around line-sizing: normal’s model working fine if line-height has significant slack, but not if it doesn't: the half-leading on the root element isn't enough to handle slight shifts in ascent/descent due to varying font-families, for example, if there's hardly any half-leading. See this video from ~11:37 - 12:30 (or just watch the whole thing if you prefer ;)
• Handling descendant inlines on the first/last line for leading-trim
• Possible benefits of splitting the choice of metric into an inheritable, independently-cascading property, leaving leading-trim to focus on whether or not to trim.

Starting from some of dbaron's comments, I suspect reworking the relationship of these two features might solve a lot of these issues.

For example, what if instead of line-sizing: legacy | normal (inheritable) and leading-trim-over/under: normal | (non-inheritable, applies to block containers, inline boxes) we had:

• text-edge-over/under: leading | normal | (inheritable, applies to inline boxes except root inline)
  • leading inline box does the usual thing of contributing half-leading
  • normal inline box ignores 'line-height', contributes margin-box edge
  • is like normal, but also trims the content-height from ascent/descent down to specified metric
• leading-trim: normal | start | end | both (non-inheritable, applies to block containers)
  • normal applies half-leading over/under the root inline box on all lines
  • start trims outer half-leading of root inline box on first line, down to text-edge metric
  • end trims outer half-leading of root inline box on last line, down to text-edge metric

[frivoal]

I think the devil's in the details of how the text-edge-over/under: are defined to work (metric of first available font vs all fonts, trim the layout bounds vs content box, etc), but the overall split into these two properties makes sense to me:

• The cascading behavior feels right: text-edge-over/under is something you'd set broadly based on your language/typographic choices, while leading-trim would be set more specifically on targeted elements
• The ability to use the value in line sizing in addition to doing it for trimming, to better deal with slight variations in sizes when there's limited slack.

[dauwhe]

[dauwhe]

Same as above, except now closed up. Basically I want a way to make this happen :)

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] Rethinking line-sizing and leading-trim, and agreed to the following:

• RESOLVED: Adopt new model described in the issue, continue working on it

The full IRC log of that discussion

Topic: [css-inline-3] Rethinking line-sizing and leading-trim
github: ttps://github.com//issues/5168
github: https://github.com//issues/5168
fantasai: Combines a lot of ideas. I can go back over line-sizing. Might be helpful if people watch video b/c it has pictures.
fantasai: Line-sizing we had several discussions on size of lines. 2 properties. line-sizing which is between current model to use line-height of each inline box and draft line box over effective height. Problem is we get line larger than author wants b/c they set line height with slack. If they add stuff they don't want extra leading added to all the lines. That's one problem
fantasai: Tried to solve by using margin edges of content box which is usually top and bottom ascent/decent.
fantasai: Problem with that model is it works fine when line-height is big enough. Doesn't work when line-height is close to 1 b/c not extra leading for shift with something like font-family. Lots of times ascent and descent are noticeably taller than glyphs
fantasai: Other discussions were about leading-trim and how to handle setting inline. Trim or not. And if you're trying to figure out metric to trim maybe you want to set it doc wide and not figure out which each time you trip. Trim usually depends on language
q?
fantasai: Might makes sense to rethink relationship between these. Prop was switch to a model where leading-trim is a switch if you trip and a separate property to say what is top and bottom edge of text for inline layout
dbaron: What does seoncd property do? Just leading trim or other things?
fantasai: Just leading trim
florian: leading-trim just trips start end or none. First says where you trip if you do and it's the switch between legacy and normal with variants of normal that lets you pick something else than text-top and -bottom and let syou switch to a different font metric for line sizing
florian: General feeling is this is going an interesting direction. if it will work depends on details which are not fleshed out. Example when we trim what do we trim. Layout box, content box? WHne trim to metric is it first available font, tallest font? Without trying varients of these I have a hard time convincing it works right, but it's worth exploring
Rossen_: Feel like we can make more progress on this issue except that its' worth exploring?
fantasai: This was one of the main issues to discuss. We can wait 5 mintues for people to think. If people need a week we need to wait
dauwhe: Wish we had a whiteboard
florian: Very much so.
ii
[fantasai works on projecting her whitboard]
https://user-images.githubusercontent.com/5687700/84923354-1d839600-b095-11ea-927c-cb17ab91de78.png
dauwhe: I put in an old drawing trying to understand sin of a superscript in a paragraph messing up spacing and it labels some font metrics. Would love to understand better how options effect this
florian: Switching between legacy and margin-box would let us not take into account green part of 5. Being able to have metric helps. Let's assume top of ascent in yellow is more far away than ink of 5. A different metric you'd be able to trim more. Ink of 5 is out of bounds. MIght be able to have enough slack on line before we could increase but nothing in the proposal does that. Can get rid of green and some of yellow
dauwhe: In real life all of yellow box fits bottom half leading of previous line
florian: Yes if there is one and not something there
dauwhe: Yes, it's a middle of block sort of example
[more whiteboard set up]
http://fantasai.inkedblade.net/style/talks/vertical-rhythm/slides.pdf
fantasai: We have a whiteboard, we have diagrams from dauwhe, we have these slides^ which I'll start with
fantasai: Slide 52 shows [draws]
fantasai: You've got a line box and another line box and another [they're stacked on top] You have leading above and below
fantasai: The line gap is the leading of the two boxes that are adjacent. You have text that's in the line box. Does it fit in the line box or do we need to increase
fantasai: Traditionally each element has its own leading. If we trim it out then can still have a different font which may or may not fit in line box. Depends on ascent or descent.
fantasai: When trying to figure out if something fits in line-box we need to ask what is bounds of thing and what do we consider fitting in the linbox? Do we assume half-leading on the next box and take that and boundries [assumed gap], include the leading.
fantasai: We take assumed gap when we're doing Ruby.
fantasai: That's one question we haven't covered yet
fantasai: Other question is what is the metric on text which we consider fitting. What is the size of the thing.
q+
fantasai: What I'm trying to answer is can we change what it means for the thing we're trying to align. What's the size of the inline box we care about to try and fit inside hte line box
I assume that using the assumed gap will still avoid collisions with previous line descenders because the gap only includes the previous half-leading
fantasai: Current is use the line height, but that's bad b/c includes half leading and we don't care about that. New is use margin-box edges which coinceisde with ascent and descent in most cases.
fantasai: Some fonts it matches height, some go a bit heigher for accents, some a lot higher for acents. So you end up with a lot of vertical space being considered.
q?
fantasai: Combining metrics iwith inheritence you let author say I only care about cap height and don't care if ascender leak.
fantasai: Trying to tak eleading-trim which is non-inherit, use the metric, and put it in an inheritable property.
fantasai: Can also say do we care about fitting and should we make what the default
fantasai: Making the linebox work for dauwhe use case it's what is size of inline box and what is size of linebox for purpose of fitting
fantasai: Prop is saying let's put some controls over what inline box is and allow it to trim to particular metrics.
fantasai: Making sense?
Rossen_: I don't think you need to explain again. We have a queue
Rossen_: Quick ask to mute on webex if you're not talking.
[webex usage tutorial]
ack florian
goal rendering: https://user-images.githubusercontent.com/5687700/84924250-4193a700-b096-11ea-8149-0266693b8f84.png
florian: The original proposal/issue wasn't discussing if we're using assumed gap. Combo of explaination and picture from dauwhe makes this interesting. Depending on what sticks out this design, unlike previous, lets us introduce another propertyt hat lets us pick between linebox and ssumed gap
florian: We'd be lacking something to decide text bounds if we do jsut that. This gives us the switch as opposed to previous design which coupled to leading-trim. Now it's re-usable and you can decide. Convinced me more this is right direction. My inclination is start spec this knowing it's not final but with sense it's better
q?
dauwhe: In general I like this idea of almost being able to pick how these stack up
dauwhe: Pick which edge will contribute here
dauwhe: I don't think I can say more and have it mean anything without making drawings for myself so I understand
q+ to ask what happens when the text doesn't fit
florian: If we say pick one do we mean metrics of first available font or of all used fonts. Is there a correct answer or a switch. Don't want a switch but not sure which
fantasai: If we're going with this model means that you're going to consider content of descendant inlines. Each inline will contrinue an edge. If contents are different font they contribute their edge. Multiple fonts on a line the line box will go from highest top to lowest bottom. Currently ascent+leading, in future have other options.
fantasai: At that point makes sense to consider fallabck fonts. Once trimming not adding a lot of excess so by default considering fallbacks is where I would start
florian: Range in there
fantasai: That would be appropriate place to start and if need stricter can add. Lots of cases where we mix fonts so weird if you say I wont font-height of this and it chops
q+
florian: If we start from content box and add padding & margin if we trim from that difference from content box and union. Content box is only first available so how do we trim from first available to all font metric. I buy everything you said so I'd try that direction
fantasai: Feels like follow-up issue
q?
florian: Yeah, probably
myles: 2 questions. First is what happens when text doesn't fit?
ack myles
myles, you wanted to ask what happens when the text doesn't fit
fantasai: Increase linebox height
myles: Just the one?
fantasai: Yes.
myles: When you drew you did black lines and than added red text. Is that the model where red text tries to fit in lines?
fantasai: Yeah. Weither this proposal or not we only accept positive leading on root inline box so the text inside the root inline are going to care that they fit in the leading bounds. If they leak outside we increase.
fantasai: Baeline of root inline will be here and they will try and fit. In either model we don't care if some text is big enough to go into leading area. If it's a bit too big it's fine. Question is what if it's big enough to go outside leading of own root inline. DO we stretch line for that case or assume half leading of previous line belongs to this.
fantasai: Stricter and looser model. In no case do we apply positive half leading to inline boxes inside
dbaron: I think myles asked if changes order of impl
fantasai: I don't think so
dbaron: I think the answer is no
florian: Spec is you align based on baselines and add leading and margin boxes if you need. Then you draw linebox around them all
myles: And in this model you do all the layout, draw a black box and it's only determined by primary font metrics and than adjust form fallback fonts?
florian: Tricky b/c lots of similar names boxes
florian: Inline boxes have 2 models depending on line-height normal. If it's normal inline box takes into account all actually used fonts incl font fallbacks. Anything other than normal then it's jsut that size that's set. Only take metrics of first available font into account to figure out where baseline goes.
q?
florian: On your time there may be more than one box. Once all inlines are in box you do top of tallest to bottom of deepest. Depending on how each box was sized is lineheight. WHat top is previous question. Top of margin box or add leading. Legacy is we add leading which is prob not what we want.
florian: New model is margin box which doesn't have leading
Rossen_: myles does that address your question
myles: Think so
fantasai: linebox model doens't change, jsut changing what is top of each box. Even if doing assume gap we can do it in same way. Only calc layout bounds of each inline box.
fantasai: In legacy it's defined as line-height. New it's text metrics based. Model on how you calc line height is not changes.
Rossen_: Couple of people on queue then break.
q?
Rossen_: We've made progress on understanding. Let's drive to conclusions
ack jfkthame
jfkthame: Question of if we're trimming through method like cap height would that be on first available. My instinct is to say only first available is better answer. Thinking from experience of page design where stability and predictability is of great value and if we merge metrics of fallback fonts it gets difficult as a designer to figure out what's going to happen.
fantasai: Main concern is to extent we've been using looser metrics that works better. When mixing fonts there's slack. Bringing to tight metrics I'm afraid you'll have substantial ink overflow when yous witch fonts.
jfkthame: I can see that. Counter by saying these are controls that will only be used by designers looking for careful control of content. If want to allow some stuff to leak that's their choice and we shouldn't stop them
myles: General principle website designers don't know if webfonts will load. THat's choice of user. We should be resilient to if different font that designer wanted.
fantasai: And you could have picked a lovely script and get chimera fallback. Trying to make sure text is readable even when unexpected thigns happen.
q+
fantasai: If your font loads properly you get what you want but if you have a fallback thing bias toward fitting by default makes sense to me.
fantasai: I think it is secondary to issue. We can open a separate item on fallbacks
Rossen_: Reasonable.
q-
dbaron: Two comments
q+ to propose a resolution
ack dbaron
s/lovely script/lovely multi-script font/
dbaron: One is about the question someone asked about which of this applies to first available font vs all
dbaron: Maybe that wasn't quite the question
dbaron: It was. First or all fonts. In this proposal that's only for text over and udner not leading leading looks at root inline box so only one font. I think that's the model for this purpose.
dbaron: Second is text edge over and under having 2 properties is weird in some cases but nec. in others. For leading and normal want one but for metric values you can't. Wonder if this should be one property that takes one or two values
fantasai: Either way should have shorthand
fantasai: I think we should push fallbacks or not to a separate issue. Look at overall structure of these properties
Rossen_: florian you want to propose a resolution?
florian: Noting that the previous proposal is marked as rough in the spec. Even if this isn't fully fleshed out including question of short/long or properties and question of fallbacks. I propose we replace the current vague proposal with this vague proposal in the spec and add these as issues to keep drilling down.
florian: I haven't heard arguments that led to us preffering the old model.
Rossen_: Let's give a 5 minute break. If there are people that have to skip that's fine but we prefer you skip. Stretch, get water, and think about florian proposal to swap the old model with the currently proposed one.


scribe+ dauwhe
Rossen_: let's go back to it
... Florian was talking about a proposal
... take this new model and replace the old model with it
... and then continue to work on it
... can we do that? do we have enough info to make that decision?
+1
Rossen_: any objections to the proposed resolution
... I hear no objections
RESOLVED: Adopt new model described in the issue, continue working on it

[tol-is]

Hi @fantasai @frivoal @dauwhe and everyone else.

I've never participated in any working groups, but I thought in this instance, you might be interested to check out a prototype I've made. It's using the negative-margin and translateY recipe to trim the bounding box and realign text to the baseline.

The 'compose' tab (top-right) is the interesting bit.

https://compositor.netlify.app/

[fantasai]

Edits made, and new draft posted.

Filed #5239 in response to some of the discussion raised by @dauwhe's diagrams.

[nileshprajapati]

Hi I was wondering if there is any update on the CSS leading trim.