Re: [csswg-drafts] [css-inline-3] Need name for inline-content-box-height-calculation-mode property

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Need name for inline-content-box-height-calculation-mode property<br>
&lt;dael> github:<br>
&lt;gsnedders> Can I suggest calling it "bikeshed"?<br>
&lt;dael> Rossen_: nominations are welcome unless fantasai you want to summarize the property<br>
&lt;dael> fantasai: We talked about use case ttml group had for this which it does not change layout calc, just where bg and border painted.<br>
&lt;dael> 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<br>
&lt;dael> fantasai: At one point a suggestion to have a value that contains all glyph bounding boxes. Might want to extend to do that.<br>
&lt;dael> fantasai: Wanted people to think about that<br>
&lt;nigel> q+<br>
&lt;dael> 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<br>
&lt;astearns> ack nigel<br>
&lt;dael> 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.<br>
&lt;dbaron> inline-box-sizing :-)<br>
&lt;dael> 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<br>
&lt;dael> 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.<br>
&lt;dael> fantasai: Property name there''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.<br>
&lt;dael> dbaron: One thought is inline-box-sizing since it's a mode switch<br>
&lt;dael> fantasai: Not terrible, but looks like might be a long hand of box-sizing<br>
&lt;dael> nigel: Sizing says width as well as height, but this is only height<br>
&lt;dael> dbaron: Inlines aren't special in width dimension on the other hand<br>
&lt;dael> fantasai: Trying to remember why not a keyword to the height prop<br>
&lt;dael> 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<br>
&lt;dael> fantasai: True<br>
&lt;dael> 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.<br>
&lt;dael> fantasai: But what if we decide some day we want long hands for box sizing? Then we're stuck.<br>
&lt;dael> Rossen_: We can make those as optional params and keep as a shorthand<br>
&lt;bradk> It would be width for vertical writing mode, right?<br>
&lt;dael> 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<br>
&lt;dael> Rossen_: Fair. [missed]<br>
&lt;dael> 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<br>
&lt;fantasai> s/having/haven't/<br>
&lt;fantasai> s/line-height/line box height calculation mode/<br>
&lt;dael> 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<br>
&lt;dael> 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<br>
&lt;dael> fantasai: I think 'mode' is generic<br>
&lt;dael> Rossen_: Let's try inline-sizing and see if we can live with it<br>
&lt;dael> fantasai: Is that okay even if we have line-sizing?<br>
&lt;dael> Rossen_: It'll be confusing but will hopefully generate interest<br>
&lt;bradk> Prefer inline-box-sizing<br>
&lt;dael> 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?<br>
&lt;dael> 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<br>
&lt;dael> nigel: makes sense<br>
&lt;dael> Rossen_: I want to see if we can get closer to resolve. Proposal was name this inline-size. Value set?<br>
&lt;dael> fantasai: I think normal|stretch and maybe extend to glyphs or something<br>
&lt;dael> fantasai: Should be possible to extend value set in the future. Maybe glyphs, maybe height of whatever is inside it<br>
&lt;dael> fantasai: but we can start with those two things since they have clear use cases.<br>
&lt;dael> Rossen_: Reasonable. Obj to renaming this to be inline-sizing: normal|stretch<br>
&lt;dael> RESOLVED: Rename this to be inline-sizing: normal|stretch<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 8 August 2018 16:29:33 UTC