[css-grid-3][masonry] Drop next value of masonry-auto-flow

[fantasai]

This value seems to cause problems with accessibility except in cases where the sizes of items are very close; and those cases are probably better handled by the masonry-threshold idea (see #9328 ).

[Loirooriol]

I disagree, as I explained in #9988.

This value seems to cause problems with accessibility

Please explain these problems. Sure, items close in document order can appear far away. But this can already happen with order, multicol, etc.

those cases are probably better handled by the masonry-threshold idea

I disagree. next brings stability, if you use it you can be sure that a small change in the size of a grid item will not completely rearrange all the following items in a chaotic way. masonry-threshold doesn't achieve that, it just changes the threshold at which things will shuffle.

Also note that next is a feature exposed in multiple masonry libraries:

• https://masonry.desandro.com/options#horizontalorder
• https://github.com/bigbite/macy.js?tab=readme-ov-file#trueorder
• https://mui.com/material-ui/react-masonry/#sequential
• https://github.com/Spope/MiniMasonry.js#parameters

And it's requested by authors: #10233 (comment)

[fantasai]

I disagree. next brings stability, if you use it you can be sure that a small change in the size of a grid item will not completely rearrange all the following items in a chaotic way. masonry-threshold doesn't achieve that, it just changes the threshold at which things will shuffle.

I don't understand your objection. masonry-threshold will get you the behavior of 'next' except in cases where the "change in size" isn't actually "small". It basically lets you choose the size at which the change in size it's no longer considered a "small". (If you set it to infinity, it gets you exactly the behavior of next.)

The problem with 'next' is that if you have a wide variation in sizes, e.g. some items 3x as tall as others, you will get the items stacking in very uncomfortable ways to follow sequentially.

[Loirooriol]

will get you the behavior of 'next' except in cases where the "change in size" isn't actually "small"

Consider a threshold of 10px. If we have three columns filled with 100px, 90px, 80px, then the next item will go into the 2nd column.
But if the last item placed in that column becomes 0.1px larger, resulting in columns filled with 100px, 90.1px, 80px, then we would place the next item into the 3rd column. And from that point on, things can change radically.

If you set it to infinity, it gets you exactly the behavior of next

That doesn't seem to follow from the definition in #9328: "among all the columns within slack distance of the shortest column, place in the startmost"

The 1st column will always be within an infinity distance from the shortest column, so all items will go into the 1st column.

I guess the logic could be modified to:

1. Let x be the last column that received an item, if any.
2. If there is no x, pick the first column and abort these steps.
3. Find the candidate columns within the threshold from the shortest one.
4. Pick the startmost candidate column that comes after x and abort these steps, if any.
5. Otherwise, pick the startmost candidate column.

I think that would really be the next behavior. Then I would be fine with dropping masonry-auto-flow: next. But masonry-threshold: calc(1px / 0) seems quite hacky, I would prefer to add a keyword for it.

[fantasai]

But masonry-threshold: calc(1px / 0) seems quite hacky, I would prefer to add a keyword for it.

What would you use it for? Afaict there's no good reason to have a value greater than 100vmax.

[Loirooriol]

As I said, to have stability. 100vmax still doesn't guarantee that. In the example below, just expanding a <details> or something that makes 1 grow will move 3 into a different column.

(Edit: I got confused with the various viewport units, I was thinking of lvh, so just imagine that the viewport and the columns are narrower).

[tabatkins]

Yeah, I do think that the "infinity" value actually has reasonable use-cases, and so we should go ahead and make it easy to do with a dedicated keyword. (In masonry-threshold; we can and should drop masonry-auto-flow, I think.)

[css-meeting-bot]

The CSS Working Group just discussed [css-grid-3][masonry] Drop `next` value of `masonry-auto-flow` , and agreed to the following:

• RESOLVED: Drop the next value of masonry auto flow

The full IRC log of that discussion

<flackr> fantasai: we have this value for masonry auto flow, instead of finding the shortest column it keeps wrapping around regardless of the heights of the columns. If you have different height columns they can be placed very far apart because it doesn't consider their size
<flackr> fantasai: it seems weird when you have slight variations in column height to jump columns (e.g. jumping to shorter column) so we had this idea for a threshold property to say if you're within some slack of other columns assume they're all the same
<flackr> fantasai: since we have that functionality which needs more precise spec, this solves the same problems that next was trying to solve but better
<flackr> fantasai: e.g. with a 100vh gap you probably don't want to do this next column behavior
<flackr> fantasai: proposal is to drop the next value from masonry auto flow
<flackr> fantasai: you can easily configure with a threshold
<TabAtkins> +1 to all that
<TabAtkins> (i do think an "infinite" keyword would be *useful* in masonry-threshold, but it's fine either way)
<flackr> astearns: IIRC, you can do it with masonry-threshold but you have to do it with a hacky calc?
<TabAtkins> `masonry-threshold: calc(infinity)` isn't terrible to write anyway
<flackr> fantasai: we could add a keyword that's infinity, but i can't think of a good use case for this. Would like to see a use case for why you'd need this
<flackr> astearns: any other comments?
<miriam> q+
<fantasai> I can't think of a reason why you'd need anything greater than 100vmax
<TabAtkins> I do have a use-case for actual infinity, but we don't need to talk about it here; it's a side-discussion from this issue.
<flackr> astearns: oriol mentioned he's opposed to dropping it without a keyword but it seemsl ike it could be a separate issue
<astearns> ack miriam
<flackr> miriam: That could be a separate issue, oriol did add an example to the thread. The use case is if you want stability, e.g. to not have disclosure widget move columns
<flackr> miriam: is that an issue if you can't choose some stable value?
<flackr> fantasai: we need to solve the stability issue somehow. You wouldn't want giant gaps in masonry regardless. You wouldn't want weird column heights / stuff jumping around. I think stability is a different issue
<flackr> miriam: makes sense
<flackr> Proposed resolution: Drop the next value of masonry auto flow
<flackr> RESOLVED: Drop the next value of masonry auto flow

[nt1m]

Edits were done here: 0ac5d9d