[css-inline] inline-sizing property name is too similar to inline-size

[AmeliaBR]

CSS Inline currently defines an inline-sizing property that changes how the height of inline boxes is calculated.

The name is a problem because we have an unrelated inline-size property for declaring width or height based on the logical writing-mode.

As far as I know, there are no implementations of inline-sizing. There are definitely implementations of inline-size.

So this issue is to bikeshed a new name for the property as described in the spec.

(Note that I personally do not understand enough about inline layout to interpret that description, so I cannot offer any good suggestions. Only that it shouldn't be the same as another property with a grammatical tense change. If someone is able to draw some pretty pictures demonstrating how this property would affect layout, that might help other people come up with name suggestions!)

[nigelmegitt]

Since inline-sizing affects the logical height of the content area, one suggestion would be to rename it to content-sizing. I'm not sure what the rules are for when to use -size vs -sizing but I guess content-size could work too, if that doesn't introduce any inconsistency with other naming conventions.

[fantasai]

Well, it affects the border box and padding box sizes as well. :) And content-size/content-sizing sounds like it would apply to much more than just inline boxes...

[nigelmegitt]

hmm, ok, making names more clearly scoped usually makes them longer, which isn't always a bad thing. inline-content-sizing-basis?

[fantasai]

One earlier suggestion was line-fill fwiw.

[estesmax]

line-box-sizing

[SelenIT]

line-fill looks good! (Though maybe fill-line would be even better?) Alternatively, maybe inline-stretch would work?

[fantasai]

Problem with line-box-sizing is we're not changing how the line box is sized, only the inline box. These are all... different things. ._.; Problem with line-fill is, although it currently swaps between filling the line vs not, possible extensions to this property could be values to change how (rather than just whether) we fit it around the text. E.g. "fit all the text including fallbacks vs. fit only the first available font's text vs fit all the content including descendants" or "use the metrics vs. use the glyph outline". Not that we will do all these things, but if we decide to do any of them, this might be where such options end up? :/ I don't have any good answers here. :(

[SelenIT]

What about something like inline-paint-area or even just inline-area?

[AmeliaBR]

OK, after reading the description again & double checking with fantasai, I think I understand this property enough to make suggestions. Starting with my own response to my requests for explanatory figures…

Here is the “normal” behavior for sizing inlines (as indicated by background colors on the various inline elements). The superscript uses the default HTML <sup> styling. The <mark> is a single element wrapping to the two contrastingly-colored inlines:

Because of the change in font size on the superscript, it's line box isn't the same height as the other line boxes. Because of its change in alignment, it also pushes the entire line it is on away from the line above, so that the other inlines do not use up the full cross-size of that line box.

In contrast, if all the inline elements used the new “stretch“ sizing, you would get (correct me if I'm wrong, @fantasai!) something that looks like this. All the inlines in that line have the same height, which fills the full height of the line, even after the line gets extra space to accommodate the superscript:

And for added clarity, an example if the wrapper <mark> element had the stretch behavior, but its child elements had the normal behavior:

---

So, back to bikeshedding…

To me, the closest analogy here is cross-axis stretch alignment in flexbox: that is, the align-items and align-self properties. But I'm not too keen on using the align prefix for a name, both because align-line-box sounds weird and because the actual alignment has already happened (based on vertical-align) prior to the stretch being applied.

But, I think it might be useful to focus on the “cross-axis” terminology, to reduce the confusion between inline elements and the inline layout direction.

Another very similar property, to me, is the box-decoration-break property, which also affects the position of backgrounds, borders, etc., on inline elements, after inline line breaking is applied.

Would it make sense to call the box-decoration-cross-size?

Or box-decoration-cross-align? (I think it's safe to use “align” here since it's clear it only applies to the “decoration”, not the text.)

[AmeliaBR]

P.S. if folks disagree with me that box-decoration is a good analogy, my next suggestion would be line-cross-size.

I don't like -fill because it already has three completely different meanings in CSS (SVG paint fill, animation-fill-mode, and column-fill).

[frivoal]

Would it make sense to call the box-decoration-cross-size?

I like the way you're thinking about this. box-decoration-* seems promising to me. For the -cross-size part, I'd be tempted to simplify to -height. It's a little bit less accurate, because height is typically meant in the physical sense, and here we're talking about logical height, but:

• It's so much shorter
• In this particular context, it's not ambiguous, since there's no corresponding property in the other axis
• There's precedent for primarily physical keywords being used in a logical sense when non ambigous: vertical-align. Even better, that precedent is on another property concerned with inline layout, so in terms of mental model, it's not particularly jarring.

TL;DR: I'd go with box-decoration-height

[SelenIT]

Maybe just box-decoration-align given that align- is already kind of reserved for block/cross axis alignment in more recently added properties?

[fantasai]

Another concern is trying to make it a bit more obvious that this property is about inline layout, and not generally applicable?

[fantasai]

Suggestions off a twitter thread: box-decoration-fill, line-height-sizing, inline-background-painting, inline-logical-height-sizing, line-stretch or inline-stretch, inline-cross-direction-sizing, inline-fill-type, inline-box-sizing, line-sizing, vertical-sizing-rule, line-fill or line-fit

[Loirooriol]

the box-decoration-break property, which also affects the position of backgrounds, borders, etc., on inline elements, after inline line breaking is applied.

However, box-decoration-break also works on non-inline elements, and on the main axis, e.g. when a block is split into multiple columns.

I'm not convinced that naming this box-decoration-something is a good thing, they seem too different concepts. As fantasai says, I would prefer something more obviously related to inline layout.

[fantasai]

Riffing off that last suggestion, maybe inline-fit? A bit hesitant about line-fit because it's not about the line box. @SelenIT’s inline-area is along the same lines.

[AmeliaBR]

This is a bit of a tangent, but it affects the name choice: Is there any interest in creating a similar property for adjusting the size of inline boxes in the inline direction? E.g., to make inline boxes at the end of the line stretch to fill the entire line width (without needing to justify the text itself, just extending the backgrounds/borders to fill the available inline size).

If such a thing were to be added in the future, then names like line-stretch, line-fill, and line-fit (and especially inline-stretch, inline-fill, and inline-fit) would all more naturally describe stretching in that direction, as opposed to stretching in the cross direction.

[AmeliaBR]

A bit hesitant about line-fit because it's not about the line box.

How so? This is about extending the dimensions of an inline element to fit the calculated dimensions of the line-box. Using line-* as the prefix is consistent with line-height — which also doesn't guarantee the final height of the line box, only this element's contribution to it!

[nigelmegitt]

Is there any interest in creating a similar property for adjusting the size of inline boxes in the inline direction? E.g., to make inline boxes at the end of the line stretch to fill the entire line width (without needing to justify the text itself, just extending the backgrounds/borders to fill the available inline size).

If such a thing were to be added in the future, then names like line-stretch, line-fill, and line-fit (and especially inline-stretch, inline-fill, and inline-fit) would all more naturally describe stretching in that direction, as opposed to stretching in the cross direction.

@AmeliaBR There is something related: see https://drafts.csswg.org/css-text-4/#line-padding-property - it is not exactly what you had in mind (as currently specified), but it is about extending the background area in the inline direction. One difference is that using it reduces the space available for layout (in a predictable way so no loops need to happen), whereas for the background height adjustment, the layout is unchanged. I'm not sure if that means we have to consider them distinctly, but the idea of a single property that affects the background painting in both axes is certainly appealing to me.

[css-meeting-bot]

The CSS Working Group just discussed inline-sizing is too similar to inline-size.

The full IRC log of that discussion

<TabAtkins> Topic: inline-sizing is too similar to inline-size
<TabAtkins> nigel: Semantics of the feature aren't in question, but name is.
<TabAtkins> nigel: Many proposals that people ahve added to the thread
<Rossen_> q?
<TabAtkins> nigel: A bit of side topic - if you think about the problem differently, this is about extending the backgroudn area in the inline direction, at the end of each line, so the text isn't up against the edge of the bg, often used in captions
<TabAtkins> florian: I think we're confusing two features here.
<TabAtkins> florian: line-padding is still called line-padding and is in Text 4.
<TabAtkins> florian: This is a diff feature. Hence its name is confusing, since it confused you about it. ^_^
<TabAtkins> nigel: Ah right, so this is more about expending the size in the block direction
<TabAtkins> nigel: But line-padding did come up as a similar topic in the thread, as a possible direction to think about things together.
<TabAtkins> nigel: Not sure they shoudl be, they seem distinct to me
<TabAtkins> Rossen_: So I see line-fit, inline-fit, inline-area
<TabAtkins> Rossen_: Then a long list from twtiter
<Rossen_> box-decoration-fill, line-height-sizing, inline-background-painting, inline-logical-height-sizing, line-stretch or inline-stretch, inline-cross-direction-sizing, inline-fill-type, inline-box-sizing, line-sizing, vertical-sizing-rule, line-fill or line-fit
<Rossen_> TabAtkins: suggest we avoid the word inline
<TabAtkins> florian: That's also the trick, it's not about "the line". It's about the block direction of inlines.
<TabAtkins> TabAtkins: Right, I just meant "line" was okay re: my objection.
<TabAtkins> faceless2: This feels similar to leading, could use that in the name.
<TabAtkins> Rossen_: Do we have other terms of art we could try to borrow?
<TabAtkins> astearns: 'leading' seems fair game in this
<TabAtkins> fantasai: It's not about leading - it doesn't affect layout.
<TabAtkins> fantasai: It just changes the size of the bg/border area of inline boxes, in the block direction.
<TabAtkins> fantasai: Other thing to consider is possible future directions for this property.
<TabAtkins> fantasai: So ultimately it'sa bout the height of the inline box
<TabAtkins> fantasai: So we might want to change how we fit around text
<TabAtkins> fantasai: Right now it's just "fit the text" or "fit the line".
<Rossen_> q?
<TabAtkins> Rossen_: Is layout not in scope for this property, then?
<TabAtkins> florian: inline-paint-height?
<TabAtkins> Rossen_: inline-background-extent?
<TabAtkins> fantasai: It affects all the box properties, in terms of where they apply graphically.
<fantasai> https://github.com/w3c/csswg-drafts/issues/5189#issuecomment-661268373
<TabAtkins> fantasai: Amelia created some nice illos
<TabAtkins> florian: I think "inline-*-extent" would have the same confusion
<TabAtkins> fantasai: I liked inline-fit because it does describe how it actually works. So like "inline-fit" or "line-fit" or something else?
<TabAtkins> florian: At some point Amelia proposed box-decoration-*, I assume we're not doing that?
<TabAtkins> fantasai: That implies more general. It's super long for one.
<TabAtkins> florian: inline-box-decoration-height? A mouthful...
<TabAtkins> jfkthame: inline-box-height?
<TabAtkins> Rossen_: That'll excite people - it says layout to me.
<tantek> better than inline-block-height
<TabAtkins> faceless2: *-shape, we kinda use that elsewhere?
<TabAtkins> Rossen_: Shape implies geometry, not just size.
<TabAtkins> fantasai: I feel like this is something we come back to during a break, after people ahve some time to think about it.
<tantek> +1 come back to it during a break
<fantasai> inline-box-fit?
<TabAtkins> Rossen_: Sounds good, we got awareness on the issue.
<TabAtkins> Rossen_: So we'll continue discussion during the break.
<dholbert> maybe "decoration" is fine after all; it was making me think "text-decoration", but now I'm remembering we have box-decoration-break etc. as well
<nigel> github: https://github.com/w3c/csswg-drafts/issues/5189

[astearns]

Given that the use case is mainly for text backgrounds, I think a text- prefix might make sense (perhaps it's easier to explain how a text- property applies to all inlines than to explain how an inline- property doesn't affect layout?). So I think text-background-size or text-background-fit might work.

[tabatkins]

Yeah, "text" seems close-enough here; it gives the right idea, at least better than "line" or "inline". Similarly, I think "background" might be close enough, even tho it affects all the other decorations too; they'll all be things surrounding the bg area, so that should probably be obvious?

I do still like @fantasai's argument for -fit in the name.

[patrickdark]

text-contain or text-content-contain seem to neatly cover the superscript case.

inline-rect-stretch is another possibility.

[fantasai]

Maybe text-box-fit then?

[nigelmegitt]

Maybe text-box-fit then?

Just for info, that was also suggested in the twitter thread.

[SamB]

... could always go back to something-or-other ...

More seriously, I was hoping to experiment with applying this facility to system color pairings, but I obviously can't do that until, well, sometime after it is given an actual name.

[bradkemper]

How about text-cross-fit? Or text-line-fit, which seems best to me, though I don't really understand the objection to the word line here. It seems pretty natural when talking about how this affects how the text box fits into the line. text-box-fit is OK too, but that also sounds like something that would be about making the box size horizontally (inline-direction) too.

[SelenIT]

A bit crazy brainstorming-style suggestion: since the property in question is about the logical height of the inline element, what about, instead of introducing a completely new property, just make the plain old height property finally applicable to inline elements? But make it accept only two values in that case — auto (default, the current behavior), and a new inline-specific value, e.g., fill-line (the new proposed behavior). Any other value would be just ignored. This seems to be not conflicting with any potentially existing (by mistake etc.) cases of setting height to inline elements.

(I would even consider accepting percentages with 100% being 100% of the line box height, calculated per fragment and potentially allowing creative designs with consistent gaps between lines with something like height: calc(100% - 4px). but realize that it's probably too much and might be not web-compatible:)

[fantasai]

@SelenIT Remembered why we didn't do that: inline-sizing is inherted, but height is not. I got that wrong in the spec draft, so it's fixed now. :/ (If we were going that direction, though, we could use the existing stretch keyword.)

See https://lists.w3.org/Archives/Public/www-style/2018Apr/0028.html and https://github.com/w3c/csswg-drafts/issues/1974 for where we added the property.

[fantasai]

Random idea: what if we made this a keyword on the text-box-edge property, instead of an independent property?