Skip to content

[css-grid-3] Make align-self/justify-self align including adjacent extra space #10275

Closed

Description

@fantasai

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.

Activity

  1. tabatkins commented on May 2, 2024

    @tabatkins
    Member

    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.

  2. bfgeek commented on May 3, 2024

    @bfgeek

    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.
  3. tabatkins commented on May 3, 2024

    @tabatkins
    Member

    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).

  4. tabatkins commented on May 3, 2024

    @tabatkins
    Member

    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.

  5. deleted a comment from Alimsayed on May 7, 2024
  6. fantasai commented on May 7, 2024

    @fantasai
    CollaboratorAuthor

    @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.)

  7. jensimmons commented on May 8, 2024

    @jensimmons
    Contributor

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

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

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

    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.
    grid3-alignment-4

    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.
    grid3-alignment-5

  8. tabatkins commented on May 8, 2024

    @tabatkins
    Member

    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).

  9. tabatkins commented on May 8, 2024

    @tabatkins
    Member

    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.

  10. fantasai commented on May 28, 2024

    @fantasai
    CollaboratorAuthor

    @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.
  11. tabatkins commented on May 28, 2024

    @tabatkins
    Member

    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.

  12. 42 remaining items

  13. css-meeting-bot commented on Jan 29, 2026

    @css-meeting-bot
    Member

    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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions