[css-inline] Draft line-box-contain proposal

[fantasai]

@dbaron had a proposal called line-box-contain for controlling how line box heights are calculated. Some aspects of this feature probably need to be revived if we're going to have baseline-to-baseline distances that aren't wiggly in simple cases like a single-font-size paragraph mixing proportional and monospace text.

Proposed values need to include:

• current behavior value ('normal'? 'legacy'?)
• value that ignores > 1em line-height values on anything other than the root inline box (slightly more conservative approach than dbaron's proposal to only use the root inline) so that the line box only grows if its contents actually extend outside the outer leading edges of the root inline
• possibly an “absolute” value that does use only the root inline? This can introduce content overlap...
• quirks mode value?
• anything else?

[kojiishi]

I'm writing this only with half-baked understanding, so there might be some incorrect parts, please read with that understanding.

After I heard a proposal from @fantasai about leading-over/-under, I'm thinking the relationship between it and line-box-contain. As far as I understand, the current scope of leading-over/-under is only for the first and the last line box, but if we apply that to all line boxes, it can also solve the baseline jitter problem, as far as line-height is set to a fixed value, am I correct?

[fantasai]

@kojiishi No, because leading-over/under gets rid of the leading. In general you want leading between lines. :) We just need to make sure the contents of the line don't contribute excess space to the line box, and that the baseline is consistently positioned within that space.

[fantasai]

Some old discussions: dbaron's line-box-contain proposal and Hyatt's proposal to www-style

[kojiishi]

Thanks, right, I think I understand it better. And the proposal looks good to me.

[css-meeting-bot]

The CSS Working Group just discussed Draft line-box-contain proposal.

The full IRC log of that discussion

<dael> Topic: Draft line-box-contain proposal
<dael> github: https://github.com/w3c/csswg-drafts/issues/3199
<dael> fantasai: We talked about having a prop that does roughly this. Some control over height of line calc. Been discussed since before my time. dbaron had interesting proposals for how to do it
<dael> fantasai: Know we need 3 behaviors: now, quirks mode, and consistant lines people want
<dael> fantasai: Drafted rough proposal with behaviors talked about.
<fantasai> https://drafts.csswg.org/css-inline-3/#line-sizing-property
<dael> fantasai: Wanted to ask WG if we want to work on this? Add something? I think need to add to inline spec, this is a rough draft.
<dael> fantasai: I think we need to add a property that does something smooth with a syntax
<dael> fantasai: Vague, but I wanted a start
<dael> myles: Been thinking about this for a while and I don't know right approach. Need backwards compat, but mode switches are confusing and multiple ways to solve line-height is extra mantanence and makes web more complicated. Not sure right way to do this
<dael> florian: Hard time seeing anything but a mode switch here. Not sure we need that many values, I'd rather 2. One does legacy or quirk depending on mode and the better behavior. Others listing leave out until proven
<dael> fantasai: The 'better behavior' says [reads]
<dael> fantasai: It might be possible to slip that in without breaking too much. Any ledding is too much. It's possible that wont' break anything
<fantasai> q+ dbaron
<dael> myles: Not saying mode switch bad. More frustration about where we got to. Also, want to say this is one of the most requested features from people that care about text. Great to solve. We're between a rock and a hard place
<fantasai> s/Any ledding/Any leading/
<dael> dauwhe: I will use it as soon as it exists
<Rossen> q?
<fantasai> s/is too much/would break, but only eliminating positive leading might be possible/
<dael> Rossen: Where do we work on it?
<dael> dbaron: A few comments
<Rossen> ack dbaron
<dael> dbaron: I think there is an alternative to mode swhich is new syntax to line-height. Mode switch-like, but not as bad in some ways
<rachelandrew> I seem to only have mic issues with WebEx, need to figure out why as I use this setup for podcasts with no issue.
<dael> dbaron: May need >1 new value. bunch of use cases for things like images in a line and in default you want images to change line height, but there are cases where images within a line and do not want a change because images are roughly the size of the text
<dael> fantasai: In terms of new keywords for line-height for ergonomics a mode switch is better. Line-height you're talking about quantity of space, not the mechanism by which you want to measure. It's a separate thought in how you want to do it.
<dael> fantasai: You want the good line height calc on the whole page and forget it. Same way as box sizing is done. I used to think it was a mistake, but the way we did box sizing was originally almost always wrong. Webdev would rather set it once on a style sheet.
<dbaron> I actually disagree about box-sizing, since I think it depends whether you care about the inside-size or the outside-size
<dael> fantasai: This is similar. You almost never want to switch. You want to set at the top and you don't want to think anymore. If you put it in line-height you have to think every time you change the line height
<dael> myles: Would a mode swtich change the way line-height is inherited?
<tantek> yes it was certainly my intent when I proposed box-sizing that it was a "just fix it so things work like I expect across all the things box related"
<myles> s/inherited/inherited or how it applies to only block elements and not inlines/
<dael> fantasai: Various behaviors prop. One that would fix most problems would be to change it so line-height is ignored on all inline elements. They just have a line-height of 1 effectively.
<dael> fantasai: Had to modify so if you set line-height <1 we add negative leading so your effect is honored
<dael> fantasai: Not that it doesn't apply, just only applies if negative leading. Applies to root and then applied to every line. As long as you're in that space, if the sizing box fits, it doesn't increase height of line or move it
<dael> myles: Any precedent for that type of behavior?
<dael> myles: I mean changing the behavior of a prop based on another prop. Not sure how I would impl
<myles> Rossen: sorry! i didn't realize the time
<dael> Rossen: Sorry to interrupt. We're 4 minutes overtime. I want convo to continue, but I want to let everyone else go. We won't resolve, but convo should continue
<gregwhitworth> scribenick: gregwhitworth
<gregwhitworth> oh
<gregwhitworth> lol
<dael> myles: I have to go too.
<dael> fantasai: Schedule a separate call about this
<dael> Rossen: Good idea
<dael> Rossen: Focused group would be good. I'll send an email to private list to see if we can get folks
<dael> fantasai: I can sent
<dael> Rossen: Have a great Thanksgiving for those of you celebrating. Talk to you next week.

[css-meeting-bot]

The CSS Working Group just discussed Proposal for a better line sizing model.

The full IRC log of that discussion

<dael> Topic: Proposal for a better line sizing model
<fantasai> https://drafts.csswg.org/css-inline-3/#line-sizing-property
<dael> fantasai: This is a very rough draft. I wanted to doc what we had discussed in the past.
<fantasai> https://dev.w3.org/cvsweb/~checkout~/csswg/css3-linebox/Attic/Overview.html?rev=1.5;content-type=text%2Fhtml#LineStacking
<dael> fantasai: Also dbaron original proposal ^
<dael> fantasai: Then other discussion listed in issues
<dael> fantasai: Main goal is try and control jitter on the line and also make sure line box sizes are consistent and baseline position is consistent across line boxes.
<dael> fantasai: In common cases. If there's a giant image maybe it grows. This is where you have same font size, but you change font family midway you create jitter. As long as author has given adequite line height it shouldn't cause line box to grow.
<nigel> q+ to ask if ruby reserve is in scope of the line height sizing
<dael> dbaron: Reason to want stable line heights sep then stable baseline patterns?
<dbaron> s/then/from/
<dael> fantasai: Mainly stable baselines. You can't see edge of linebox. If linebox is same height but baseline changes it makes jitter. This isn't wanting a line grid. That's a separate issue.
<dael> astearns: This is more about having a vertical rhythm within an element
<dael> fantasai: Right
<astearns> ack nigel
<Zakim> nigel, you wanted to ask if ruby reserve is in scope of the line height sizing
<dael> nigel: Is this considering Ruby height?
<dael> fantasai: Current way Ruby is defined to work is if you have enough leading that double that would create enough space for Ruby you don't increase line. Line to line is half above and half below.
<dael> nigel: Ruby is in the line area
<dael> fantasai: Typically half in linebox and half outside. Assuming previous line box with space
<dael> Rossen: Which is one of the problems because everyone does something with first line and last. Hopefully can do better here
<dael> fantasai: For Ruby you want to make sure enough space. When doing first or last line you don't want to consider Ruby when placing because you usually have enough padding. Leading trim prop discussed at F2F as to where you consider top of line ot be. That exclused Ruby so lets you place as people expect
<dael> fantasai: If we want a switch that includes Ruby that's a different switch.
<dael> fantasai: I think most of the time people are asking for Ruby to be excluded so they line up
<dael> nigel: My expectation seems different. If you have or might have a Ruby before you want to make sure line space is big enough. Same with after. Have to be independent of content before. In the case of a caption where text keeps changing need to make sure baseline appears in consistent place weither or not Ruby appears
<dael> fantasai: For captions layout rules are slightly different then docs. Doing that we would need some way of saying leave this much space, but only on the top. Right now extra space is applied top and bottom
<dael> nigel: Exactly, yes
<dael> fantasai: That would prob have to be sep property. You'd want to say add this much extra space but only here
<dael> nigel: Before or after or both. A first and last line selector that adjusts it so you can be clever about where you put Ruby
<dael> fantasai: nigel is that issue filed?
<dael> nigel: There was question about Ruby reserve. I have to go hunting
<myles> Can’t have last lime pseudo because it’s contents van change what the last line is
<dael> fantasai: We need to think about that more. but I think it's a slightly different discussion. might end up interacting on same prop.
<dael> fantasai: Does make sense we need to solve
<dael> nigel: One outcome we should aim for is if we include Ruby reserve or not it's clear which we do. If there's a way to add Ruby reserve does it add line sizing? put a wrapper? need to be clear whatever the model is
<dael> fantasai: Might be able to add values to leading-trim property we discussed. It adds space instead of trims
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3199
<nigel> -> https://github.com/w3c/csswg-drafts/issues/3240 [css-inline] Leading control at start/end of block #3240
<dael> fantasai: nigel can you file and issue?
<nigel> -> https://github.com/w3c/csswg-drafts/issues/2998 [css-ruby][css-text-decor-4] Add over-most-under-last value to ruby-position & text-emphasis-position for captioning #2998
<dael> nigel: There was a TTML issue I put in IRC. Prob closest we have
<dael> nigel: Doesn't include reserve so that's the issue that needs raising
<dael> nigel: Happy to raise it
<dael> nigel: You think that Rubby reserve should be in leading control?
<dael> fantasai: Might make sense. Should look
<dael> nigel: IN Ruby?
<dael> fantasai: In CSS Inline
<dael> fantasai: Discussed at TPAC and decided to add the property
<dael> nigel: 3240 perhaps?
<dael> fantasai: Yes, that's the one. Haven't edited it into spec yet
<dael> nigel: I'll raise an issue
<dael> fantasai: I think the main thing we need is a behavior where we ignore the line-height prop on any inline level boxes. So toher than root inline. Continue to height only if leaking outside of line height set by root.
<dael> fantasai: That would solve a lot of the cases. Might be possible to jsut do it.
<dael> florian: The better behavior and the box model behavior are they distinct because different use cases or because one might be able ot be a default?
<dael> fantasai: Different behaviors.
<dael> fantasai: I don't know how useful box model is, but it uses margin box of inline boxes
<dael> koji: Can you describe different?
<dael> fantasai: Current line sizing model takes the root inline and applies half leading. every inline box ignores margins, border, padding and intead uses line height to calc leading. Makes sure line box includes text content and leading above and below
<dael> fantasai: Box model behavior doesn't use line height on any inline element. It uses margin edges and uses that as the sizing box and tries to make sure line box is big enough to contain all margin boxes.
<nigel> -> https://github.com/w3c/csswg-drafts/issues/3351 [css-inline][css-ruby] Allow ruby reserve space to be allocated #3351
<dael> fantasai: Right now we ignore margin box for inline boxes
<nigel> I raised the issue above in relation to the ruby reserve conversation.
<dael> dbaron: Almost feels like it's not clear to methe use case for better rather then box. Seems silly to not include a border if you have one. If you want to not you can use negative margin
<dael> florian: I think that's what I was thinking. You probably want either of those in similar cases. Might want better over box only because we might be able to make the better behavior a default. If we can't make better a default ight not want it
<dael> dbaron: I'm not sure risks are different between
<dael> florian: I'm not sure if there is a difference
<dael> fantasai: I listed everything we've discussed so we can talk about what we have
<dael> fantasai: If we think box model is better we can do that
<dbaron> I guess the risk is that it's more different from the current model
<dael> florian: On that train of thought, if we think better behavior might be usable as a default would anybody be willing to try as an impl and go first? Or is it jut a thought experiment and we don't need to consider it.
<dael> dbaron: Skeptical about making any of them the default
<dael> myles: With dbaron. I don't think we'd impl first to make them a default
<dael> astearns: Concern over unknowns? I assume first someone would impl and see what edge cases before any consideration of trying as a default.
<dael> gregwhitworth: I think you impl first. Similar to how we allow border boxsizing to change. Let authors use it. If it goes well we can do a trial
<dael> gregwhitworth: What authors are begging for this? I heard a few use cases. Is it high demand?
<dael> fantasai: People paying attention to typography are frustrated
<dael> dauwhe: I'm horrified that a superscript breaks line height
<nigel> +1
<astearns> +1
<fantasai> s/frustrated/frustrated that even within a paragraph where the font size doesn't change, the baseline-to-baseline spacing is inconsistent/
<dael> myles: Gotten many requests of people interested in line layout for typography. They have baseline to baseline metrics from a designer and there's nothing they can to to make that happen
<jensimmons> There are entire books written about how to deal with the stupidity of the defaults. People who care about typography & graphci design are intensely frustrated with the status quo.
<dael> florian: Asked about default because if neither can be default no reason to have both. Prob box model over better behavior. If we can have a default maybe cause for both. But it's not obvious we do.
<dael> florian: Absolute behavior seems more risky. That makes sense as sep. Also wondering if this is a value where authors think it's right and on the user's computer something is different and there's overlap
<dael> fantasai: Very skeptical absolute behavior is right to add. Creates a large risk of things going wrong. I added it for completeness. Def not first edition.
<dael> florian: Quirks is different behavior. Is there request for opting into quirks sep from being in quirks?
<dael> fantasai: Don't think so
<dael> ??: No
<myles> S/??/myles/
<dael> florian: Seems we could have 2 values. Current or Quirks and the other being box model behavior
<dael> fantasai: Legacy and normal?
<tantek> Agreed. the quirks behavior here is crap. never heard anyone ask for it deliberately. though hard to tell since it's a default :(
<dael> florian: Yeah.
<dael> florian: dbaron I think you explored a prop with finer granualrity. Are there varients you thought useful not here?
<fantasai> dbaron's proposal was https://dev.w3.org/cvsweb/~checkout~/csswg/css3-linebox/Attic/Overview.html?rev=1.5;content-type=text%2Fhtml#LineStacking
<dael> dbaron: It's poss there might be some cases where you want...if you need something like image-like text you might be okay with them extending. Pretty edge case-y
<dael> myles: [missed] authors not to have image like text. Or other way around
<myles> s/[missed]/we try to tell
<dael> fantasai: dbaron prop had sizing around glyph bounding block. Sometimes useful. One way to incorp is have it in inline sizing. Be able to switch and say this box uses glyph bounding. This switch will inherit through entire doc and it'll be just this box needs glyph sizing.
<dael> fantasai: That's the value I think prompted webkit to impl. Mainly to allow a box to pick up less space. Larger font size with cap letters it made the line increase even with no ink
<dael> koji: No strong pref between better and box models. Agree better to start with two values.
<dael> koji: Question: What do we do for line-height:normal in the case where all browsers correct. We correct for the containment box
<nigel> q+ to ask for box-model what happens with negative half leading to other inline boxes than those whose block-axis margins, borders, and padding are zero
<dael> florian: Can you remind me in what way it collects things across elements? I remember line-ehight:normal on a single, but not on multiple
<dael> koji: We unifity allthe metrics so that all fonts are considered in the height. THen the inline box height is included in the parent height. Since we're only taking root line box I guess we need to change to treat all
<dael> myles: 2 desires. If there's content in the middle that's really big you want increase. A little bigger you don't want. We need rules to distinguish the cases
<dael> fantasai: THe better behavior and box model are supposed to have it be that if box leaks outside line box we increase size of box. Leading means if you're only a little bigger you'll fit inside unless you've got a really tight line height. Both break down on how they handle maintaining font size and changing font family. Normally you have enough leading for that, but if you're setting line-height:1 it'll create jitter and I'm not sure how to handle that case
<dael> nigel: Targetting avoidance of jitterbetween paragraphs?
<dael> fantasai: Mainly within
<dael> nigel: Typesetting you might have 2 paragraphs, one with a modification that adjust the line height. If it has paragraphs on other side it looks weird if other paragraphs have different. Typographic is here's my line spacing, use it everywhere.
<dael> fantasai: That's what we're trying. It's the same as when we have multiple line paragraph and only one line grows. We want to solve that and related cases where there's content that fits within the space but also when you try and include leading and there's already leading
<dael> astearns: MIght be good to add to draft text here are the cases we want to address. And here are the ones we're not fixing like an inlineblock with different line height.
<dael> fantasai: inline block is like an image in this case We don't know what's inside
<dael> florian: What we just discussed answers koji. line-height:normal shouldn't do anything special with looking at font metrics. If they do stick out line height increases. Shouldn't do anything different there then numeric values. Then we'd have the problems where have different line heights because different font
<dael> fantasai: Normal should behave as 1.1 or whatever it resolves on on the root inline. Take the value off the first available would be a reasonable behavior
<dael> koji: I think I like current, not sure it's well spec. Current impl of line-height:normal that takes all points. Doesn't give consistent but it makes text legible.
<dael> fantasai: If authro wants consistent they can set a value
<dael> myles: Valuable to take all used fonts into consideration. Could be all text comes from font far down list. But if we do that we get jitter. Sounds like we want to figure it all out and then layout, but that's 2 pass and prob too slow
<dael> fantasai: What if you ran calc based on all available fonts. Whatever you have in system. Prob too many fonts
<dael> koji: [missed]
<dael> myles: We create objects lazily so we're halfway through paragraph before realize have to create a font
<dael> myles: Either before layout paragraph you have 0 fonts or you layout twice. Or anyway do 2 passes
<dael> astearns: Seems to me kind of consideration koji said where look at whole line and metrics and decide what to set that happens after root inline box. You choose root inline box and for every actual line you look at used fonts, figure out metrics, and see if fits in root inline. If it does, no change. If it doesn't, line may increase in height
<dael> florian: I think I'm with you. Having a hard time thinking through
<dael> koji: I think we need some detailed definition written down for review. In general I like the line setting proposal. Make it 2 values. Probably have 2 behaviors, one when it's normal and one when it's not.
<dael> myles: Worth consulting other prop apps like inDesign and MS Word. They have line height. Should consider.
<dael> astearns: No one else have half leading like web does
<dael> myles: Yeah, but we should figure out what they do
<dael> koji: Agree. At least line sizing we're trying to define new model so learning what other apps do and try to incorperate is good
<chris> half-leading is an exclusively CSS weirdness. Even XSL-FO didn't attempt to adopt it.
<dael> fantasai: Summary: We want to have a line sizing prop with 2 vaues, legacy and normal. Hearing preference for box model behavior rather then better behavior. I can redraft to bring down to that.
<dael> fantasai: Looks like issue with how does line-height normal: interact
<dael> fantasai: Other issues?
<astearns> ack nigel
<Zakim> nigel, you wanted to ask for box-model what happens with negative half leading to other inline boxes than those whose block-axis margins, borders, and padding are zero
<dael> nigel: I was reading text on box model. There's a not covered case. Not sure how important. It talks abotu applying postive and negative half leading. Neg it says [reads]. What about thosewhose margin/border/padding are not 0?
<dael> fantasai: Then we don't add negative half leading to that element.
<dael> fantasai: That sentence was trying to address...if you have a ling height of 0.8 you're adding negative half leading. One of our goals was to not have a span inside your line increase the line size unless it's significantly larger. Let's say all text is samefont and size. We apply leading. Then we encounter a span. Without this exception the box will be sizes as a line height of 1. It'll be taller b/c didn't apply line-height so it causes line to increase.
<dael> fantasai: If line height causes negative half leading we need to take the amount it shrinks and apply to other boxes. Don't want to do it >1 because then we grow too much.
<dael> florian: And we don't have to do that with padding or border?
<dael> fantasai: If you applied padding or boder you decided to take control and will be responcible to apply the negative margins
<dael> nigel: Seems liek a special case that will surprise. Imagine you only want a border around a piece of text, no other change. Seems like a surprise if it causes an increase?
<dael> fantasai: Could add negative half leading unconditionally
<dael> nigel: More obvious to me
<dael> florian: Might want to leave as an option issue, but unconditional seems to make sense to me.
<dael> myles: Which spec is this?
<dael> fantasai: Inline
<dbaron> q+
<dael> myles: Not there already?
<dael> fantasai: It's where it's drafted
<astearns> ack dbaron
<myles> https://drafts.csswg.org/css-inline-3/ ?
<dael> dbaron: Seems to me there are different use cases that lead to neg half leading and might want different things to happen. Font has a relatively large...the size you add the leading around is large. Line height might do negativehalf leading b/c tight line height. Doesn't mean you want to remove from everything else
<dael> dbaron: On the other hand fonts that do that don't play well with this model either
<dael> myles: Case you described is common b/c designers don't know their font metrics. They put a font and adjust line height until it looks good. Theydon't know if that crosses the invisible line of ascent and descent
<dael> fantasai: Can say it adjusts the content box so then the padding and border added outside leading
<dael> florian: That makes sense to me
<dael> nigel: Couldn't that cause clipping?
<dael> fantasai: No, don't clip inline boxes
<nigel> s/Couldn't/And that wouldn't
<dael> florian: I think that's quite reasonable. Experiments might show something else, but thinking it's a good model
<dael> myles: We seem to have a lot of ideas and theories. If this goes into a spec it should have a don'timpl marker
<dael> astearns: Section does have that.
<dael> astearns: This discussion of negative half leading is that a sep issue?
<dael> fantasai: Yeah. We'll put it unconsitionally it adjust content box and file and issue to discuss further
<dael> astearns: Action for you?
<dael> fantasai: Yeah
<dael> ACTION fantasai put it unconditionally negative padding adjust content box and file and issue to discuss further
<trackbot> Created ACTION-875 - put it unconditionally negative padding adjust content box and file and issue to discuss further [on Elika Etemad - due 2018-12-05].
<dael> astearns: Converging on 2 value legacy and new thing. Will need to be a lot of cleaning up of section in spec and adding details discussed and then going over spec text.
<dael> fantasai: Yes and going over filed issues
<dael> fantasai: Should this prop apply to block containers or inline boxes?
<dael> koji: Prefer block container I think
<dael> dbaron: If inherited and it can apply to inline boxes there's not a disadvantage to doing it. Might bea little weird in terms of effects.
<dael> astearns: Want to avoid a case where we introduce shift because we introduct it to an inline container that breaks across lines
<dael> dbaron: Haven't htought through inline boxes well
<dael> fantasai: I'll have it apply to inline boxes and file an issue
<dael> astearns: Sounds good
<dael> astearns: Anything more on this topic?
<dael> astearns: I'm really happy we had this conversation. Winnowing the options and having something more focused for the future is an excellent result.
<jensimmons> +1 to what Alan said
<dael> astearns: Likely can't take over the regular call in the future, I'm happy to have extra line layout TF calls when needed.
<dael> fantasai: I'll draft up stuff and we'll meet again soon

[fantasai]

Note: There were some interesting comments related to this from dbaron in https://lists.w3.org/Archives/Public/www-style/2020Feb/0020.html

[fantasai]

Agenda+ to decide whether to publish with the previously-drafted text or not. (I don't think it's good, it's just a starting point.) https://drafts.csswg.org/css-inline-3/#line-sizing-property

[css-meeting-bot]

The CSS Working Group just discussed Draft line-box-contain proposal, and agreed to the following:

• RESOLVED: Publish css-inline

The full IRC log of that discussion

<heycam> Topic: Draft line-box-contain proposal
<heycam> github: https://github.com/w3c/csswg-drafts/issues/3199
<heycam> fantasai: this is the main one we've discussed a bunch about drafting alternate models for line layout
<heycam> ... some of the ideas are captured in the draft
<heycam> ... do we want to publish with them in the draft?
<heycam> ... it's not in any way final, question is just whether we want a placeholder in there to solicit discussion on the ideas
<heycam> florian: agree it's not final, but it's worth leaving in to get extra review
<heycam> dbaron: I think it's mostly reasonable, though there's a sentence in there I don't understand
<heycam> ... "half-leading is inserted inside the content box edges rather than overlapping the pbm areas"
<heycam> fantasai: I can remove that sentence
<heycam> ... if you wanted a line height that's less than 1, somehow we have to reduce the size of the box that we're considering for the height of the line
<heycam> ... otherwise it would increase the height of the line box
<heycam> ... there's needs to be a reduction at least on the margin
<heycam> ... somewhere we need to reduce the size
<heycam> dbaron: I guess there's 2 questions. one is what you said makes it sound like you want line height to change where the pbm go
<heycam> ... when half leading would be negative
<heycam> fantasai: yes
<heycam> ... that's one option
<heycam> ... but we could also not do that. it's not critical, I can remove it from the draft for now, but we should discuss at some point
<heycam> ... other option is to reduce the margin box
<heycam> dbaron: I think it might be good to move into an issue
<heycam> ... might be good to remove that part, but otherwise I'm fine with publishing with this in
<heycam> Rossen_: any other reasons to hold back publishing?
<fantasai> baseline-source: auto | first | last
<heycam> fantasai: we also added a baseline-source property for #861
<heycam> ... the syntax wasn't resolved yet
<heycam> ... we also added a leading-trim proposal, which again is not anywhere near final, but it's tracking the discussion we've had in the past
<heycam> ... then I pulled in a bunch of CSS 2.1 with florian's help, so we have some line height calculations defined in this draft. no changes, just imported text
<heycam> florian: just to clarify, the 2.1 changes we're talking abotu (actually 2.2) we resolved
<heycam> ... they've been reverted to clean up CSS 2
<heycam> ... the wording we had resolved on and applied to CSS 2 is not present anywhere if we don't publish it here
<heycam> ... so I'm strongly in favor of publishing it
<fantasai> Summary of the changes we didn't quite resolve on at https://lists.w3.org/Archives/Member/w3c-css-wg/2020AprJun/0137.html
<heycam> Rossen_: any objections, to this and publishing inline?
<heycam> fantasai: issue needs to remain open
<heycam> ... the issue on adding a new model for line height calculations. the issue isn't closed yet, despite publishing
<florian> s/reverted to clean up CSS 2/reverted along with every other edit to CSS 2 as part of a temporary clean up/
<fantasai> all changes at https://drafts.csswg.org/css-inline-3/#changes
<dbaron> In 3.5 "Leading Control" I'd change "the ascend and descent font metrics" to change "ascend" to "ascent"
<heycam> RESOLVED: Publish css-inline
<fantasai> https://github.com/w3c/csswg-drafts/issues/862