Oh yeah, that makes sense. You need it to work like this, in fact - you can't align the contents of the column as a whole, because spanning items cross columns. So it needs to align each contiguous run of single-column items.

Does this then imply that spanning items can never be aligned in that axis? We don't otherwise meaningfully distinguish between a masonry of single-column items and an identical masonry with double the half-width columns and all items being two-column spanners, but I don't think I'm opposed to making that distinction.

Generally supportive of the stretch capability.

Two points:

• When defining stretch needs to be explicit on how percentages resolve. E.g. potentially want flex behaviour here.
• Need to be careful for the other non-stretch values, e.g. it runs into the same "ordering becomes unclear" issue, but perhaps less so here.

By "flex behavior" you mean "treat %s as indefinite if they're resolving against an indefinite dimension" (and stretching doesn't make a dimension become definite).

Oh, I didn't properly read the title - I don't think this is appropriate for *-self to do, for the same reason we don't let align-self work in Block Layout. I think this should be a *-content behavior.

@tabatkins I think you're confused... this issue is about aligning only the last item adjacent to the gap above spanner, not the entire stack of items above the spanner. I agree that aligning the entire stack could be useful, too, but it runs into the problems @bfgeek outlined for #8207 which is why that feature was removed.

(I thought it was a weird request at first, but then seeing Jen explaining why she needed it in her demos, it started to make sense why it would be useful to do this.)

Current result if some items span multiple columns. There can be spaces left (look at second column).

What if an author wants to apply align-items: end, instead of the default start? (Or align-self: end.)

Or they could use align-items: center / align-self: center.

Or use stretch along with object-fit: cover. Two images are cropped in this case — and the rest of the images are not. And there are no empty spaces.

They could use align-self: start on enough items to fill the first row, and use align-self: end on the rest of the items to get this result.

Oh, huh. Only aligning the last one seems fairly odd to me.

Jen's examples look good and the use-cases are definitely reasonable, but all the images have only one element being affected, so it doesn't demonstrate the difference in question. If there were multiple elements, especially if there were 3+, I think it would look odd if all it did was change it from "the entire stack of elements is start-aligned" to "the entire stack of elements is start-aligned except for the last one, which is end-aligned". This seems extra true for center. (stretch might look okay, tho.)

I agree that aligning the entire stack could be useful, too, but it runs into the problems @bfgeek outlined for #8207 which is why that feature was removed.

No, in that issue @bfgeek was objecting to the ability to align the contents of each track independently - giving one track start alignment, another end alignment, etc. He recognized the value in being able to align all the tracks in a given direction: "The use-cases I've seen here typically align masonry axis tracks together rather than individually." and the following paragraphs in his comment.

Non-start alignments applied to the whole masonry can somewhat misalign the reading order from the dom order, but generally not to an enormous degree (and generally no more than what masonry-threshold can do).

They could use align-self: start on enough items to fill the first row, and use align-self: end on the rest of the items to get this result.

Ooh tho, this case does look pretty good, but isn't addressed by using align-content as I suggest. But it still hits the same issues I mentioned, where if the later picture (of the hallway/stairwell) wasn't alone in its stack, but rather was one of three or more images between the two spanners, having just the bottom one be end-aligned would look odd. It also means you have to guess at the number of tracks you'll get, which isn't generally safe since we think auto-fill masonrys will be common.

This might argue, then, for a masonry-specific alignment property, which can distinguish between stacks which are touching spanners on only one side, and those actually wedged between spanners on both sides.

An additional plus of that approach is we can then keep align-content consistent with Grid, where it aligns the masonry stack as a whole, and align-self consistent with all the layout modes, where it does nothing because you can't align individual elements when they're laid out in a group like that.

@tabatkins I think you're right that this needs the ability to select across what's at the top vs bottom of a stack of items. However I do think that adjusting just the one item, and not the whole stack, is reasonable here. You don't want the whole layout to shift as you're adding items, for example, but you might want to have the bottom row of items stretch to create a flat line--until more content loads in after it.

I think the way to do this would be with align-items, and following the text-align longhands pattern (text-align-all/text-align-last). Like this:

• align-self aligns a masonry item within the space it occupies plus the adjacent gap (if any), as described above by @jensimmons
• align-items-first applies to items in the first row (of grid/masonry/flex).
• align-items-last applies to items in the last row (of grid/masonry/flex).
• align-items-all applies to all the other items.
• align-items is a shorthand for all three.
• align-self overrides align-items, as usual.

Hm, I don't think that quite works, but it's close. In particular, if you wanted to avoid ragged edges or holes, and only wanted to adjust the first/last items, then you'd want stretch on the first/last ones, and then end on the non-first items in each of the first stacks, but start on the non-last items in the last stacks. And I'm not sure which behavior you'd want for stacks in the middle, that aren't touching the top or bottom of a masonry track.

I think we need to play with the value space some more before we hit on the right answer.

Doing some analysis of the issue, we believe that whatever behavior is expected from the alignment properties it can be accomplished by aligning stacks of items as a whole.

Just to confirm that we share the same understanding, we consider that a stack of items is a group of all contiguous single-track items contained between the boundaries of either the masonry container or an item spanning multiple tracks. In the following figure, we highlight all different stacks of items in pink.

Regardless of whether we want to align the stacks as a whole or only the first/last item within them, keeping track of these stacks is required in some capacity and it shouldn't shift layout.

On the other hand, we believe that allowing self-alignment outside of these stacks will be problematic and should be avoided. Consider the following example:

The pink and blue items have opposing alignment properties which have a non-intuitive interaction with each other. It only gets worse if we add more items to the stack pushing each other.

We think that aligning the stacks as a whole is a superset of aligning the first/last item in a stack and should suffice to address the most interesting use case of avoiding holes between items or ragged edges at the end of the stacking axis.

In order to avoid ragged edges at the end, one could expect align-items-last to control the behavior of the last stack in each track. Note that Tab’s proposal of keeping everything aligned as start, while making only the last item in the stack stretch is a definable behavior for the whole last stack. However, we also picture an alternate version that stretches all items in the stack proportionally:

Another example, avoiding holes using the align-items-all for stacks in the middle:

Finally, without more concrete use cases for other property values, we don’t see how center or end make sense. We believe we only need to define some stretching capability to address gaps and revisit whenever is necessary.