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)

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.

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.