[css-grid-3] The initial value of masonry-slack should be 0

[Loirooriol]

https://drafts.csswg.org/css-grid-3/#masonry-slack says that the initial is masonry-slack: 1em.

I think that the correct masonry-slack slack value is very dependent on the contents of the masonry, so 1em may not work well in some cases, and will probably just cause unnecessary confusion to authors.

I think it's better to default to 0, and then let authors choose what works best for them.

[fantasai]

I disagree, because of I think the default should be something that generally works well: and I suspect there are very, very few use cases where a value less than 1em would be appropriate.

It's also easier to understand that there's a value you can tweak here when it isn't zero: the behavior is already there, so you go looking for the knob rather than assuming there isn't one.

1em isn't particularly arbitrary; we use it for column-gap. The one change that might make sense is switching it to 1lh since it's a block-axis adjustment.

[tabatkins]

Yeah, a 1px difference between two columns should definitely not cause the masonry items to be misordered by default; that would just be a bad default behavior. We can discuss exactly what value the default should be, but it should definitely be something non-zero but fairly small, approximately 1em.

[jensimmons]

I really like the idea of 1lh as the default.

I agree that's about the right amount — it's kind of the smallest visible difference. And of course, authors can change it.

Maybe we want to do 1em for the sake of consistency, since that measurement is the default in a lot of places (paragraph margins, for instance). But I really like 1lh. That is what would have been used all over, if the unit had existed decades ago.

[Loirooriol]

a 1px difference between two columns should definitely not cause the masonry items to be misordered by default

I have tested desandro's Masonry and Macy.js, and both definitely do that by default. I didn't even see an option to change this, so it doesn't seem something authors expect or are asking for (unlike #10883 btw).

While I agree that using some positive value is desirable in most cases, I'm not convinced that the confusion that it may cause if we set 1em by default is a net gain.

we use it for column-gap

Yeah I guess that's a good point, though.

I really like the idea of 1lh as the default.

I don't see 1lh as a particularly better choice than 1em, it seems to me that masonry is typically used for image galleries where the height of a text line isn't much relevant.

[fantasai]

Thinking about it more, 1lh makes sense in the block axis, but not so much in the inline axis, so I think we should just keep it as 1em.

While I agree that using some positive value is desirable in most cases, I'm not convinced that the confusion that it may cause if we set 1em by default is a net gain.

The positioning of items when slack is zero is itself pretty surprising. And worse for accessibility. So strongly believe we should have a noticeable default value.

[css-meeting-bot]

The CSS Working Group just discussed [css-grid-3] The initial value of `masonry-slack` should be 0.

The full IRC log of that discussion

<khush> oriol: it would be better to summarize the prop. another issue for naming it
<khush> with masonry we place the item into a track that is less filled.
<khush> with this prop you can provide a threshold so instead of doing it strictly order is preserved
<khush> current spec tentative initial value is 1m
<khush> i think it should be set to 0
<kbabbitt> s/1m/1em/
<khush> was investigating js frameworks which provide this
<khush> all of them have the strict value
<khush> they offer 2 possibilties: masonry-slack: 0 or infinite
<astearns> ack keithamus
<khush> when you set it to a positive value, no framework supports it
<khush> authors don't expect or ask for it
<khush> maybe it can be beneficial. exact value which will work well is highly dependent on the use-case
<khush> so just supporting 1em is confusing
<astearns> ack fantasai
<Zakim> fantasai, you wanted to point out they don't have a concept of masonry-slack
<khush> align with frameworks and set initial value to 0
<TabAtkins> +1 to fantasai's point
<khush> fantasai: the reason why frameworks don't have non-0 initial value since there is nothing other than infinity
<khush> this is a concept frameworks don't have
<khush> allows placements to occur in a more natural way for the user
<khush> slight diff of a few pixels jumping to a diff track breaks accessibility and sequencing order also
<khush> it would be better to have a non 0 initial value
<khush> 1em is used for gap
<khush> significantly more than 1px but less enoug
<khush> almost no use-case for anything less than this
<astearns> q+
<khush> oriol: i don't get the accessibility problem. reorder happens anyway in other cases
<khush> fantasai: when you start mixing span values, you have this problem. span: 1 doesn't cause jumping backwards.
<khush> the most common case won't have this jumping around
<khush> as long as your slack is big enough yoy're always moving fwd
<khush> masonry-slack being too small makes it not obvious why the movement happened
<khush> noticeable difference between 2 columns for you to go higher. user won't understand why we moved unless the slack is high
<khush> astearns: i don't understand the argument that an em's worth of slack is more natural when none of the current libs give you that facility
<khush> fantasai: they just didn't think of it
<khush> astearns: it's been long enough. why no feature request?
<khush> fantasai: we might be able to do better than the js framework though
<khush> astearns: 1em is currently spec'd?
<khush> fantasai: yea
<khush> TabAtkins: +1 to fantasai
<khush> oriol: this would align with col-gap. it's initial value is normal.
<khush> should we do something more along the lines?
<khush> not 0 but normal keyword
<khush> oriol: there may be different cases where the value changes due to other things and changing the initial value would be harder
<khush> so yes
<khush> fantasai: sounds good to me
<khush> oriol: i still believe defaulting to a positive value will trigger confusion
<khush> fantasai: happily surprised?
<khush> astearns: any implementations?
<khush> fantasai: not yet
<fantasai> s/happily surprised/surprised and delighted/
<dholbert> I have a concern that 1em as a magic value might produce unexpected layouts, if a user has a different font-size in their UA stylesheet etc
<dholbert> 1em as a threshold of "a distance that a user may notice" is a bit fiddly
<dholbert> which means I think I agree with a "normal" value, but I'm not sure how it should be defined. :)
<fantasai> dholbert, it's not 1rem, it's 1em :)
<khush> astearns: we don't have a basis to decide this issue. let's implement and get feedback from authors. revisit once we have that data
<fantasai> so it will always scale with the font the author chose
<kbabbitt> +1 astearns
<miriam> I would consider 1lh…
<khush> fantasai: let's resolve on what we have
<dholbert> fantasai: if a user sets a minimum font-size in their browser, I thought that still impacts 1em sizing? need to confirm