- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jun 2020 17:09:21 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-inline-3] Rethinking line-sizing and leading-trim<br> <dael> github: ttps://github.com/w3c/csswg-drafts/issues/5168<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5168<br> <dael> 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.<br> <dael> 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<br> <dael> fantasai: Tried to solve by using margin edges of content box which is usually top and bottom ascent/decent.<br> <dael> 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<br> <dael> 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<br> <Rossen_> q?<br> <dael> 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<br> <dael> dbaron: What does seoncd property do? Just leading trim or other things?<br> <dael> fantasai: Just leading trim<br> <dael> 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<br> <dael> 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<br> <dael> Rossen_: Feel like we can make more progress on this issue except that its' worth exploring?<br> <dael> 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<br> <dael> dauwhe: Wish we had a whiteboard<br> <dael> florian: Very much so.<br> <fantasai> ii<br> <dael> [fantasai works on projecting her whitboard]<br> <dauwhe> https://user-images.githubusercontent.com/5687700/84923354-1d839600-b095-11ea-927c-cb17ab91de78.png<br> <dael> 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<br> <dael> 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<br> <dael> dauwhe: In real life all of yellow box fits bottom half leading of previous line<br> <dael> florian: Yes if there is one and not something there<br> <dael> dauwhe: Yes, it's a middle of block sort of example<br> <dael> [more whiteboard set up]<br> <fantasai> http://fantasai.inkedblade.net/style/talks/vertical-rhythm/slides.pdf<br> <dael> fantasai: We have a whiteboard, we have diagrams from dauwhe, we have these slides^ which I'll start with<br> <dael> fantasai: Slide 52 shows [draws]<br> <dael> fantasai: You've got a line box and another line box and another [they're stacked on top] You have leading above and below<br> <dael> 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<br> <dael> 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.<br> <dael> 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.<br> <dael> fantasai: We take assumed gap when we're doing Ruby.<br> <dael> fantasai: That's one question we haven't covered yet<br> <dael> fantasai: Other question is what is the metric on text which we consider fitting. What is the size of the thing.<br> <florian> q+<br> <dael> 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<br> <astearns> I assume that using the assumed gap will still avoid collisions with previous line descenders because the gap only includes the previous half-leading<br> <dael> 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.<br> <dael> 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.<br> <Rossen_> q?<br> <dael> fantasai: Combining metrics iwith inheritence you let author say I only care about cap height and don't care if ascender leak.<br> <dael> fantasai: Trying to tak eleading-trim which is non-inherit, use the metric, and put it in an inheritable property.<br> <dael> fantasai: Can also say do we care about fitting and should we make what the default<br> <dael> 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<br> <dael> fantasai: Prop is saying let's put some controls over what inline box is and allow it to trim to particular metrics.<br> <dael> fantasai: Making sense?<br> <dael> Rossen_: I don't think you need to explain again. We have a queue<br> <dael> Rossen_: Quick ask to mute on webex if you're not talking.<br> <dael> [webex usage tutorial]<br> <Rossen_> ack florian<br> <dauwhe> goal rendering: https://user-images.githubusercontent.com/5687700/84924250-4193a700-b096-11ea-8149-0266693b8f84.png<br> <dael> 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<br> <dael> 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<br> <dauwhe> q?<br> <dael> dauwhe: In general I like this idea of almost being able to pick how these stack up<br> <dael> dauwhe: Pick which edge will contribute here<br> <dael> dauwhe: I don't think I can say more and have it mean anything without making drawings for myself so I understand<br> <myles> q+ to ask what happens when the text doesn't fit<br> <dael> 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<br> <dael> 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.<br> <dael> 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<br> <dael> florian: Range in there<br> <dael> 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<br> <jfkthame> q+<br> <dael> 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<br> <dael> fantasai: Feels like follow-up issue<br> <dauwhe> q?<br> <dael> florian: Yeah, probably<br> <dael> myles: 2 questions. First is what happens when text doesn't fit?<br> <Rossen_> ack myles<br> <Zakim> myles, you wanted to ask what happens when the text doesn't fit<br> <dael> fantasai: Increase linebox height<br> <dael> myles: Just the one?<br> <dael> fantasai: Yes.<br> <dael> 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?<br> <dael> 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.<br> <dael> 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.<br> <dael> fantasai: Stricter and looser model. In no case do we apply positive half leading to inline boxes inside<br> <dael> dbaron: I think myles asked if changes order of impl<br> <dael> fantasai: I don't think so<br> <dael> dbaron: I think the answer is no<br> <dael> florian: Spec is you align based on baselines and add leading and margin boxes if you need. Then you draw linebox around them all<br> <dael> 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?<br> <dael> florian: Tricky b/c lots of similar names boxes<br> <dael> 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.<br> <Rossen_> q?<br> <dael> 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.<br> <dael> florian: New model is margin box which doesn't have leading<br> <dael> Rossen_: myles does that address your question<br> <dael> myles: Think so<br> <dael> 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.<br> <dael> 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.<br> <dael> Rossen_: Couple of people on queue then break.<br> <Rossen_> q?<br> <dael> Rossen_: We've made progress on understanding. Let's drive to conclusions<br> <Rossen_> ack jfkthame<br> <dael> 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.<br> <dael> 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.<br> <dael> 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<br> <dael> 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.<br> <dael> 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.<br> <florian> q+<br> <dael> 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.<br> <dael> fantasai: I think it is secondary to issue. We can open a separate item on fallbacks<br> <dael> Rossen_: Reasonable.<br> <florian> q-<br> <dael> dbaron: Two comments<br> <florian> q+ to propose a resolution<br> <Rossen_> ack dbaron<br> <fantasai> s/lovely script/lovely multi-script font/<br> <dael> dbaron: One is about the question someone asked about which of this applies to first available font vs all<br> <dael> dbaron: Maybe that wasn't quite the question<br> <dael> 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.<br> <dael> 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<br> <dael> fantasai: Either way should have shorthand<br> <dael> fantasai: I think we should push fallbacks or not to a separate issue. Look at overall structure of these properties<br> <dael> Rossen_: florian you want to propose a resolution?<br> <dael> 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.<br> <dael> florian: I haven't heard arguments that led to us preffering the old model.<br> <dael> 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.<br> <dael> <br type=5min><br> <dauwhe> scribe+ dauwhe<br> <dauwhe> Rossen_: let's go back to it<br> <dauwhe> ... Florian was talking about a proposal<br> <dauwhe> ... take this new model and replace the old model with it<br> <dauwhe> ... and then continue to work on it<br> <dauwhe> ... can we do that? do we have enough info to make that decision?<br> <dauwhe> +1<br> <dauwhe> Rossen_: any objections to the proposed resolution<br> <dauwhe> ... I hear no objections<br> <fantasai> RESOLVED: Adopt new model described in the issue, continue working on it<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5168#issuecomment-645502937 using your GitHub account
Received on Wednesday, 17 June 2020 17:09:24 UTC