[css-grid] Decide on a name for item-slack

[Loirooriol]

#9328 (comment) didn't resolve on the name for this property.

In the spec it has been tentatively added as masonry-slack: https://drafts.csswg.org/css-grid-3/#masonry-slack

Other ideas from #9328 are masonry-threshold, masonry-placement-threshold, masonry-strictness, masonry-adjust, masonry-skip, masonry-sensitivity.

[Loirooriol]

I'm liking masonry-tolerance (as in https://en.wikipedia.org/wiki/Engineering_tolerance).

I'm not fond of "slack" because as a non-native English speaker that's a word that I learned considerably later than the others.

"strictness" and "sensitivity" can seem to imply that a higher value will choose the track by comparing the running positions more strictly, while it's actually the opposite.

[fantasai]

Current spec proposal is item-slack, fwiw.

[chriskirknielsen]

I really like item-tolerance as suggested in the item-flow proposal post, as it maps to a physical, real-world concept (afaik used in manufacturing specs), whereas "slack", feels a little more… "jargony", if that makes sense?

[astearns]

I wonder whether more information about what gets the slack would improve the property name. I see that this was suggested in the earlier issue, using -placement-, which is a bit long (but I still like it). Perhaps -fit- would work?

item-fit-slack
item-fit-tolerance
item-fit-allowance

[davidwebca]

There is item-fit-clearance, item-fit-buffer, item-fit-room, but I like item-fit-tolerance the best because it very much describes what it does without too much potential interference from other meanings (buffer = video buffer? / clearance = clearing css floats?).

Other funny suggestions : item-fit-wiggle-room, item-fit-leeway, item-fit-laxity.

[DavidJCobb]

The name definitely needs to at least imply that the property pertains to how items are fit into the layout -- specifically, the concept of "fitting" a thing in. Things like "placement" don't, and absent any other qualifiers, words like "tolerance" and "threshold" are way too vague. (What is it the threshold of?) As far as the two-word suggestions go, item-fit-tolerance is the closest to being good.

The word "slack" conveys looseness, whereas it seems like higher values would cause items to be fit into the layout in more tightly compressed arrangements. So "more slack" leads to a tighter, not looser, fit? Seems backwards.

WebKit's explainer describes the property as inviting the browser to "cram" extra items into tight spaces. Maybe item-cram or item-cram-tolerance? The word "cram" isn't super formal, but it well conveys the idea of squeezing things into too tight a space for them to fit comfortably. The word "fit" is less specific about this. I do sort of think that mentioning "tolerance" is good to distinguish this from e.g. a per-item or overall "limit" on how things can be crammed (and it leaves room to actually add a "limit" property in the future if that's ever deemed a good idea).

[davidwebca]

I think the focus needs to be on describing the extra space and not the result of that extra space to keep the property semantically distinct. item-cram-tolerance describes only one of the potential result - cramming more elements in a specific space - but according to the explainer, and if I understand correctly, that's not necessarily what would happen in a grid/masonry scenario. The name of the property, in my opinion, needs to say: "Here's a value that describes extra space for your calculation, wether it be for compacting or positioning the next item." When I think about it that way, I'd rather forgo the fit as a prefix and it makes me consider ìtem-fit alone, item-boundary, item-cap, item-edge, item-bleed or item-safety (those last two inspired by print design).

Just to sum up my understanding:

In flexbox, a higher number will allow a larger element to be compacted into the current row before the algorithm moves to the next. If in the current row there is 20em of space left, if the item-tolerance is 10em and if the next item to place is 30em, that item will be crammed into the 20em that's left with potential recalculations depending on the packing, spacing and stretching properties. With an item-tolerance of 9em, the cutoff point would be at 29em and so the next item would be placed on a new row.

In grid, a higher number will allow to re-equalize columns in a specific direction. If column 1 has 10em of free space, column 2 has 20em of free space, the next item should usually be placed in column 2 to fill the column that has the most empty space. An item-tolerance of 10em would place the next item in column 1 instead of column 2 because both columns would now be considered having 20em free space - it effectively "virtually" backfills the empty space with the value we provide and then restarts its column choice algorithm.

Please correct me if I'm wrong in my current understanding.

But if all of this is right, item-tolerance, item-fit alone and item-threshold are much more specific in what they accomplish while being generic enough to accommodate both display-mode paradigms graciously.

[css-meeting-bot]

The CSS Working Group just discussed [css-grid] Decide on a name for `item-slack` , and agreed to the following:

• SUMMARY: Contemplate replacing 'item-' with 'flow-'
• RESOLVED: rename item-slack to item-tolerance ... for now.

The full IRC log of that discussion

<kbabbitt> oriol: we have this property item-slack
<kbabbitt> ... what it does is allow diverging from sorting items into shortest track
<kbabbitt> .. with tracks filled to a similar amount it allows following source order instead of shortest
<kbabbitt> .. value of 0 means strictly shortest track
<kbabbitt> ... value of infinity means strictly source order
<kbabbitt> ... this is named 'item-slack' in spec
<kbabbitt> ... but we didn't resolve on that name
<kbabbitt> ... not fond of "slack" as non-native Engish speaker
<kbabbitt> ... there were also some other ideas like strictness, or ??
<kbabbitt> ... they seem to imply a higher value will implyu more strictness
<kbabbitt> ... where it's the opposite
<astearns> s/??/sensitivity/
<kbabbitt> ... other ideas were threshold, adjust, skip
<kbabbitt> ... I propose 'tolerance'
<kbabbitt> ... which some people were recommending recently
<bkardell> s/implyu/imply
<dbaron> We can always change the property values to match the name.
<kbabbitt> ... when I proposed this it was with masonry prefix
<kbabbitt> ... now that it could be item tolerance, could be more confusing of how you're adding tolerance
<kbabbitt> ... astearns proposed 'item-fit'
<kbabbitt> ... someone also suggested "cram"
<jensimmons> q+
<kbabbitt> ... but people liked the word tolerance
<kbabbitt> fantasai: cram doesn't work for all the cases we're talking about
<kbabbitt> TabAtkins: can't imply squeezing or stretching
<kbabbitt> ... can be used for either
<astearns> ack jensimmons
<fantasai> florian: "fuzz"?
<kbabbitt> jensimmons: let's rename it
<kbabbitt> ... I like tolerance too
<TabAtkins> I'm okay with 'tolerance'
<kbabbitt> ... it is true that it is confusing by itself
<kbabbitt> ... item-fit-tolerance is good but long
<TabAtkins> i don't super like any of the shorter words than tolerance
<kbabbitt> ... would be all for replacing slack with fit-tolerance
<kbabbitt> TabAtkins: also a fan of tolerance
<kbabbitt> astearns: everyone ok with adding 'fit'?
<kbabbitt> fantasai: don't love it but don't have better suggestion
<kbabbitt> astearns: we're not tolerating the item
<kbabbitt> TabAtkins: all the item properties are about placing item, so item-tolerance would also be about placing the item
<kbabbitt> ... think it already suggests roughly what we're aiming at
<kizu> +1 to tolerance as well
<kbabbitt> astearns: item-fit-tolerance was my best name
<kbabbitt> TabAtkins: I'm always looking out for property name lengths
<kbabbitt> dholbert: item-fit reminds me of object-fit which is unrelated
<kbabbitt> ... that slight overlap is confusing
<kbabbitt> dbaron: don't reject names because they don't go with values
<kbabbitt> ... can always change values to go with names
<kbabbitt> TabAtkins: here the values are lengths not keywords
<kbabbitt> fantasai: what if we rename item-flow to flow
<kbabbitt> ... then it would be flow-tolerance, flow-direction, ...
<kbabbitt> TabAtkins: doesn't that land us against flow layout module that describes block?
<ethanjv> I like flow
<kbabbitt> fantasai: besides display keyword is awkward
<kbabbitt> ... otherwise work really well
<ethanjv> https://drafts.csswg.org/css-grid-3/#flow-control
<kbabbitt> TabAtkins: can we look at item properties real quick?
<kbabbitt> fantasai: replace 'item' prefix with 'flow'
<kbabbitt> ... then 'item-flow' becomes 'flow'
<kbabbitt> TabAtkins: means we can't have a shorthand
<kbabbitt> fantasai: item-flow -> flow is the shorthand
<kbabbitt> kbabbitt: "flow-pack"?
<kbabbitt> fantasai: yes
<kbabbitt> astearns: don't want to resolve on this change right away
<kbabbitt> astearns: Proposed: rename item-slack to item-tolerance
<fantasai> SUMMARY: Contemplate replacing 'item-' with 'flow-'
<kbabbitt> bkardell: it's very difficult for people looking in to understand stability of our decisions
<kbabbitt> ... we should say, as a currently best working answer but probably to be re-bikeshedded later
<kbabbitt> astearns: that applies to all our resolutions
<kbabbitt> bkardell: should be more specific here since it's being cited in intents to ship
<oriol> Hard to hear Brian
<kbabbitt> TabAtkins: this one is pretty explicitly tentative
<kbabbitt> bkardell: can we put the word tenative in the resolution?
<kbabbitt> florian: all our decisions can be revisited, when we know they will be, dont print your book yet
<kbabbitt> astearns: Proposed: rename item-slack to item-tolerance ... for now.
<kbabbitt> astearns: objections?
<kbabbitt> RESOLVED: rename item-slack to item-tolerance ... for now.
<kurt> The spec uses the word "threshold" - The item-slack property specifies what the threshold is for considering tracks to be “the same height”, causing them to fill in order.