You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-grid-3] Make align-self/justify-self align including adjacent extra space #10275
This came up earlier in discussions with @jensimmons and again when she was creating demos: spanning items create gaps above them, and it would be useful to be able to align within those gaps. In particular, applying stretch or end alignment would improve the effects in demos such as https://webkit.org/demos/grid3/photos/ (e.g. in "Every 5th item").
The proposal is to use the self-alignment properties in the masonry axis to align an item above a spanner or at the end of the masonry grid in the space allotted to it + the subsequent gap.
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.
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.)
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).
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.
The CSS Working Group just discussed [css-grid-3] Make align-self/justify-self align including adjacent extra space, and agreed to the following:
RESOLVED: baseline alignment values are treated as their fallback value
RESOLVED: No, alignment of one item doesn't depend on alignment of other items.
The full IRC log of that discussion
<sgill> alisonmaher: recently agreed to add align-self justify-self in masonry axis but still details remaining
<sgill> which alignment keywords apply? should baseline alignment be an option? assume no
<fantasai> PROPOSED: baseline alignment values are treated as their fallback value
<fantasai> RESOLVED: baseline alignment values are treated as their fallback value
<fantasai> https://github.com//issues/10275#issuecomment-3760830496
<fantasai> Lovely diagram ^
<sgill> alisonmaher: second piece is related to last comment in issue
<sgill> if there is a spanner that is an alignment subject and has an item above it that is an alignment subject
<dholbert> q+
<sgill> is there extra space created for the first one
<astearns> ack dholbert
<sgill> dholbert: for simplicity i want to say no
<sgill> but would create pretty broken result if everything was centered aligned and some things didn't look that way
<fantasai> PROPOSED: Extra space provided to an item's alignment container is exclusive to it.
<sgill> do we expect this to be a common use case
<sgill> astearns: in the diagram, if the blue item has center alignment and is the only thing w/ it, seems like the intent is for it to be center aligned relative to other items
<sgill> fantasai: don't want to make alignment of one object depend on alignment of another
<sgill> TabAtkins: all self alignment values apply in a way that do not depend on other elements
<fantasai> RESOLVED: No, alignment of one item doesn't depend on alignment of other items.
Activity
tabatkins commentedon May 2, 2024
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.
bfgeek commentedon May 3, 2024
Generally supportive of the stretch capability.
Two points:
tabatkins commentedon May 3, 2024
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).
tabatkins commentedon May 3, 2024
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.
fantasai commentedon May 7, 2024
@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.)
jensimmons commentedon May 8, 2024
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 defaultstart? (Oralign-self: end.)Or they could use

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

stretchalong withobject-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: starton enough items to fill the first row, and usealign-self: endon the rest of the items to get this result.tabatkins commentedon May 8, 2024
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. (stretchmight look okay, tho.)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-thresholdcan do).tabatkins commentedon May 8, 2024
Ooh tho, this case does look pretty good, but isn't addressed by using
align-contentas 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-contentconsistent with Grid, where it aligns the masonry stack as a whole, andalign-selfconsistent 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.fantasai commentedon May 28, 2024
@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 thetext-alignlonghands pattern (text-align-all/text-align-last). Like this:tabatkins commentedon May 28, 2024
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
stretchon the first/last ones, and thenendon the non-first items in each of the first stacks, butstarton 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.
42 remaining items
css-meeting-bot commentedon Jan 29, 2026
The CSS Working Group just discussed
[css-grid-3] Make align-self/justify-self align including adjacent extra space, and agreed to the following:RESOLVED: baseline alignment values are treated as their fallback valueRESOLVED: No, alignment of one item doesn't depend on alignment of other items.The full IRC log of that discussion
<sgill> alisonmaher: recently agreed to add align-self justify-self in masonry axis but still details remaining<sgill> which alignment keywords apply? should baseline alignment be an option? assume no
<fantasai> PROPOSED: baseline alignment values are treated as their fallback value
<fantasai> RESOLVED: baseline alignment values are treated as their fallback value
<fantasai> https://github.com//issues/10275#issuecomment-3760830496
<fantasai> Lovely diagram ^
<sgill> alisonmaher: second piece is related to last comment in issue
<sgill> if there is a spanner that is an alignment subject and has an item above it that is an alignment subject
<dholbert> q+
<sgill> is there extra space created for the first one
<astearns> ack dholbert
<sgill> dholbert: for simplicity i want to say no
<sgill> but would create pretty broken result if everything was centered aligned and some things didn't look that way
<fantasai> PROPOSED: Extra space provided to an item's alignment container is exclusive to it.
<sgill> do we expect this to be a common use case
<sgill> astearns: in the diagram, if the blue item has center alignment and is the only thing w/ it, seems like the intent is for it to be center aligned relative to other items
<sgill> fantasai: don't want to make alignment of one object depend on alignment of another
<sgill> TabAtkins: all self alignment values apply in a way that do not depend on other elements
<fantasai> RESOLVED: No, alignment of one item doesn't depend on alignment of other items.
[css-grid-3] Clarify that baseline self-alignment in the stacking axi…
[css-grid-3] Clarify self-alignment. #10275
[Masonry] Implement fill-reverse for alignment cases
[Masonry] Implement fill-reverse for alignment cases
[Masonry] Implement fill-reverse for alignment cases
[Masonry] Implement fill-reverse for alignment cases
Bug 2026922 [wpt PR 58787] - [Masonry] Implement fill-reverse for ali…
Bug 2026922 [wpt PR 58787] - [Masonry] Implement fill-reverse for ali…
Bug 2026922 [wpt PR 58787] - [Masonry] Implement fill-reverse for ali…
Bug 2026922 [wpt PR 58787] - [Masonry] Implement fill-reverse for ali…