Repository navigation
[css-inline] inline-sizing property name is too similar to inline-size #5189
Description
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!)
Activity
nigelmegitt commentedon Jun 10, 2020
Since
inline-sizingaffects the logical height of the content area, one suggestion would be to rename it tocontent-sizing. I'm not sure what the rules are for when to use-sizevs-sizingbut I guesscontent-sizecould work too, if that doesn't introduce any inconsistency with other naming conventions.fantasai commentedon Jun 10, 2020
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 commentedon Jun 10, 2020
hmm, ok, making names more clearly scoped usually makes them longer, which isn't always a bad thing.
inline-content-sizing-basis?fantasai commentedon Jun 11, 2020
One earlier suggestion was
line-fillfwiw.estesmax commentedon Jul 19, 2020
line-box-sizingSelenIT commentedon Jul 19, 2020
line-filllooks good! (Though maybefill-linewould be even better?) Alternatively, maybeinline-stretchwould work?fantasai commentedon Jul 20, 2020
Problem with
line-box-sizingis we're not changing how the line box is sized, only the inline box. These are all... different things. ._.;Problem with
line-fillis, 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 commentedon Jul 20, 2020
What about something like
inline-paint-areaor even justinline-area?AmeliaBR commentedon Jul 20, 2020
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-itemsandalign-selfproperties. But I'm not too keen on using thealignprefix for a name, both becausealign-line-boxsounds weird and because the actual alignment has already happened (based onvertical-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-breakproperty, 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 commentedon Jul 20, 2020
P.S. if folks disagree with me that
box-decorationis a good analogy, my next suggestion would beline-cross-size.I don't like
-fillbecause it already has three completely different meanings in CSS (SVG paintfill,animation-fill-mode, andcolumn-fill).10 remaining items
AmeliaBR commentedon Jul 21, 2020
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 withline-height— which also doesn't guarantee the final height of the line box, only this element's contribution to it!nigelmegitt commentedon Jul 22, 2020
@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 commentedon Jul 30, 2020
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//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//issues/5189
astearns commentedon Jul 30, 2020
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-sizeortext-background-fitmight work.tabatkins commentedon Jul 30, 2020
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
-fitin the name.patrickdark commentedon Aug 11, 2020
text-containortext-content-containseem to neatly cover the superscript case.inline-rect-stretchis another possibility.fantasai commentedon Aug 13, 2020
Maybe
text-box-fitthen?nigelmegitt commentedon Aug 18, 2020
Just for info, that was also suggested in the twitter thread.
SamB commentedon Sep 10, 2021
... 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 commentedon Sep 13, 2021
How about
text-cross-fit? Ortext-line-fit, which seems best to me, though I don't really understand the objection to the wordlinehere. 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 commentedon Sep 13, 2021
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
heightproperty 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 settingheightto 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 likeheight: calc(100% - 4px). but realize that it's probably too much and might be not web-compatible:)fantasai commentedon Nov 14, 2022
@SelenIT Remembered why we didn't do that:
inline-sizingis inherted, butheightis 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 existingstretchkeyword.)See https://lists.w3.org/Archives/Public/www-style/2018Apr/0028.html and #1974 for where we added the property.
fantasai commentedon Jun 21, 2024
Random idea: what if we made this a keyword on the
text-box-edgeproperty, instead of an independent property?