[css-grid-3] [masonry] Should items with a definite row/column be placed first?

[celestepan]

In the test masonry-item-placement-001.html:

<grid>
  <item style="grid-column:1">6</item>
  <item>5</item>
  <item style="margin-top:10px">3</item>
  <item style="grid-column:span 2">1</item>
  <item>2</item>
  <item style="grid-column:3/span 2">4</item>
</grid>

Blink, Webkit, and Gecko all perform placement differently, and we'd like to confirm what the correct behavior is.

Blink's placement looks like this:

Webkit's placement result:

Gecko's placement result (which matches the current associated wpt reference file):

It looks like the main difference is that Webkit places items with explicit rows/columns first, and Gecko doesn't prioritize the minimum running position and places the item displaying 2 at the first position after the auto placement cursor.

It's not specified in the "Layout Algorithm" section of the masonry spec if items with a definite row/column should be placed first: https://drafts.csswg.org/css-grid-3/#masonry-layout-algorithm. In grid, explicitly-placed items are placed first: https://drafts.csswg.org/css-grid-2/#auto-placement-algo, but we wouldn't need that for masonry since we don't have the concern of auto-placed items occupying the exact cell that explicitly-placed items should take up.

@tabatkins @fantasai

[alisonmaher]

The Gecko rendering (and the reference file for the test) seem broken to me, so I would support either the Blink or Webkit behavior.

Webkit's behavior more closely matches the ordering Grid would choose. However, I tend to lean more toward the Blink rendering since it more closely matches source ordering. As @celestepan mentioned, in masonry, we don't need to handle placed items first because we only allow explicit placement in one axis. As such, we don't run the same risk as Grid where we could fill a spot that a later item was trying to be placed within.

[tabatkins]

Yes, the spec doesn't say anything about doing definite items first because it doesn't intend for you to: all items are done in the order they're encountered.

Grid has to do definite items first, because otherwise it might run out of space in the track the item wants to go into. We don't want to either cause overflow (from forcing the item into a full track) or violate the authors' explicit constraint (by moving it somewhere else), so the only option is to do the definite items first, so they can take up the space they need before auto-placed items fill in the rest of the space.

Masonry has no such constraint, so we can do the more natural thing and just take things in the order they're specified (with order letting authors rearrange things explicitly when they desire).'

Blink's behavior is correct in this example. The ref behavior is just relying on non-dense Grid auto-flow, which isn't correct for Masonry; that is, the test is wrong and should match Blink. (If you set grid-auto-flow: dense in the ref, it gives the correct behavior.)