[css-inline-3] Need name for inline-content-box-height-calculation-mode property

[fantasai]

We need an actually usable name for the unnamed property we resolved to add in response to #1974

See https://drafts.csswg.org/css-inline-3/#inline-box-dimensions

[nigelmegitt]

Can I suggest inline-box-content-height as a long but semantically close fit to what the property does? I can!

[css-meeting-bot]

The Working Group just discussed Need name for inline-content-box-height-calculation-mode property, and agreed to the following:

• RESOLVED: Rename this to be inline-sizing: normal|stretch

The full IRC log of that discussion

Topic: Need name for inline-content-box-height-calculation-mode property
github: https://github.com//issues/2989
Can I suggest calling it "bikeshed"?
Rossen_: nominations are welcome unless fantasai you want to summarize the property
https://drafts.csswg.org/css-inline-3/#inline-box-dimensions
fantasai: We talked about use case ttml group had for this which it does not change layout calc, just where bg and border painted.
fantasai: Current behavior is defined as in css 2. It's possible we might want other values at some point. I don't know 2.1 but it used font metrics or maybe 1em for height of content box
fantasai: At one point a suggestion to have a value that contains all glyph bounding boxes. Might want to extend to do that.
fantasai: Wanted people to think about that
q+
fantasai: I have no good suggestion. I have a constraint that we've had discussions about how line-box height is calc. We need to be clear that this name is not that
ack nigel
nigel: The ttml requirement is that the background areas go to the line areas. So if there's a way tht eline area heights can change we need to track that in proprty values.
inline-box-sizing :-)
nigel: Made a suggestion a few days ago and someone had another so there are suggestions. When I looked at draft spec it make me want to call it inline-box-content-height. Going back to your point if the line edges might move then maybe the fill value should be called line
fantasai: Another thing is we do have plans to have a height keyword called stretch which take sa cotnainer and says I want you to fill that. Might be another keyword that makes sense. Could rename fill to stretch.
fantasai: Property name there's...it's the content height but effects border-box height and shouldn't be confused with inline-size. Cannot be mixed up with changing how line height or box height are calc.
dbaron: One thought is inline-box-sizing since it's a mode switch
fantasai: Not terrible, but looks like might be a long hand of box-sizing
nigel: Sizing says width as well as height, but this is only height
dbaron: Inlines aren't special in width dimension on the other hand
fantasai: Trying to remember why not a keyword to the height prop
Rossen_: If it's only to inlines height is a bit of an overkill. YOu'd also have to add it to all other heights and this is just used value
fantasai: True
Rossen_: I gravitate toward dbaron 's reasoning. This is the switch we use for flipping different ways of box model. Also having something similar for inline calc which is not bad.
fantasai: But what if we decide some day we want long hands for box sizing? Then we're stuck.
Rossen_: We can make those as optional params and keep as a shorthand
It would be width for vertical writing mode, right?
fantasai: But if we decide we do want longhands this is what they wuld be. WE can say inline-sizing, but not inline-box-sizing
Rossen_: Fair. [missed]
fantasai: Also having decided name for line-height property. I think that one should be line-sizing or maybe line-box-sizing. If we go with that inline-sizing is close and it gets confusing
s/having/haven't/
s/line-height/line box height calculation mode/
Rossen_: Seems like we have inline-sizing, inline-box-sizing which captures it but don't want to use because box-sizing shorthand. inline-box-content-height proposed on github and also inline-box-mode also from github
Rossen_: Can we narrow down and if we need to change later, well, as I said this is a favorite topic for the group so we can bikeshed more
fantasai: I think 'mode' is generic
Rossen_: Let's try inline-sizing and see if we can live with it
fantasai: Is that okay even if we have line-sizing?
Rossen_: It'll be confusing but will hopefully generate interest
Prefer inline-box-sizing
nigel: Why are you focusing on inline ness rather then the content area that you're setting. Content area of inline boxes, sure, but aren't content areas always inline?
fantasai: No, alll boxes have content area. And we're not only setting content area, we're also doing margin and border etc. It's the margin area that fills the line box. By default the margins padding etc are by default 0, but if they're bigger the cotnent box would be smaller
nigel: makes sense
Rossen_: I want to see if we can get closer to resolve. Proposal was name this inline-size. Value set?
fantasai: I think normal|stretch and maybe extend to glyphs or something
fantasai: Should be possible to extend value set in the future. Maybe glyphs, maybe height of whatever is inside it
fantasai: but we can start with those two things since they have clear use cases.
Rossen_: Reasonable. Obj to renaming this to be inline-sizing: normal|stretch
RESOLVED: Rename this to be inline-sizing: normal|stretch