[css-grid-3] Drop masonry-auto-flow: definite-first?

[tabatkins]

The spec doesn't really define masonry-auto-flow: definite-first, but has the text:

First, picking definite items first for placement can be inhibited by specifying the ordered keyword so that a plain order-modified document order is used instead.

This seems to imply that definite-first causes all the masonry items with a definite track to be placed first, at the "top" of the masonry, and then all the rest of the masonry items flow in. I think it also implies that definite-first is the default value, chosen when you don't specify either keyword (including in the initial value).

I think the reasoning here is that Grid places definite items first, before auto-flowing items, and so Masonry is just matching that default behavior. But that's not really true - Grid's placement algo has four categories of items (fully definite, row-definite, column-definite, and fully auto), and treats each category differently. It places fully definite first, then auto-flows the row-definite items into their chosen row, then just auto-flows the column-definite and fully auto items all together, with column-definite just setting the cursor to its chosen column (possibly advancing the cursor to the next row, if needed).

Fully-definite and row-definite are placed early solely to avoid overlap; otherwise, it's trivial for auto-placement to accidentally fill the areas those items wanted to occupy. Outside of that constraint, tho, they're auto-flowed in order as much as possible (which is why column-definite items aren't re-ordered at all).

I believe Masonry items are most similar to a column-definite grid item - they want a particular column, but are fine with being bumped to a later "row" if needed. They should be auto-flowed with all the other items by default.

This also allows for the potentially useful behavior of having "clearing" items that span all the tracks, and guarantee that following items show up below them. This is useful in Multicol, and I anticipate it being similarly useful in Masonry.

---

I think it would be acceptable to just make ordered the default, rather than definite-first, if there were good reasons to still keep definite-first around. I... can't think of any, tho. If people do want to reorder some items to the front of the masonry, the order property makes that trivial already. Do we have reasonable use-cases for wanting the definite-first behavior, enough to justify it as a keyword?

(If we did drop it, and we potentially dropped next as suggested in #9988 and #10232, then we wouldn't actually have any choices left and could drop the property entirely.)

[css-meeting-bot]

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

• RESOLVED: drop the definite-first value of masonry-auto-flow

The full IRC log of that discussion

<dbaron> ScribeNick: dbaron
<dbaron> TabAtkins: the spec doesn't currently define the masonry auto flow ? value
<dbaron> TabAtkins: can be inferred what it means
<dbaron> TabAtkins: distinction between items in a definite track versus items purely auto placed. That value means that anything you place indefinite will go first and then all auto-placed ones below it.
<dbaron> TabAtkins: I think it's a bad behavior.
<dbaron> TabAtkins: intended to match with grid 's behavior but it doesn't.
<dbaron> TabAtkins: what grid does is it breaks items into 4 categories.
<dbaron> TabAtkins: things with definite row + column, a definite row (any column), a definite column (any row), and fully auto placed
<dbaron> TabAtkins: it handles these in order of strictness
<dbaron> TabAtkins: in order to minimize chance of overflow
<dbaron> TabAtkins: so first it places things that are fully definite (row + column)
<dbaron> TabAtkins: next it places anything with a definite row, since if the row gets filled up it will overflow the row
<dbaron> TabAtkins: finally it flows column placed things and auto-placed things together as one category in order
<dbaron> TabAtkins: this is because column-placed things, worst case, they get shifted to the next column (??), so almost as flexible as auto-placed
<dbaron> TabAtkins: masonry stuff is all the final two categories
<dbaron> TabAtkins: so I think the default behavior is to match grid and flow them all together
<dbaron> TabAtkins: I think there's no actual use case for definite first.
<dbaron> TabAtkins: if you want things first, use the order property.
<fantasai> dbaron: I think it makes sense
<dbaron> s/column (??)/row/
<dbaron> fantasai: any objections to dropping the definite-first value of masonry-auto-flow
<dbaron> RESOLVED: drop the definite-first value of masonry-auto-flow

[nt1m]

Edits were done here: 0ac5d9d