[css-grid] Ability to clamp track spanning

[MikeMatusz]

Currently, if any element spans multiple columns when using auto-fill, the grid is incapable of gracefully handling sizing below that amount of columns. The extra columns get squished, as demonstrated in the following example:

Using a syntax like span-minmax(1, 3) to clamp the spanning (as proposed by @MatsPalmgren here) would allow the grid to be fully responsive.

One such use case mentioned on that issue is:

• Have "featured" items span multiple columns, but only when the columns become available

[mirisuzanne]

It seems to me like this should be solvable, and would be very useful. Here's my proposal (actual function name TBD):

• span(<integer>, [ <integer> | all ]?), where…
• The smaller integer is a min span, the larger is a max span
• all keyword represents until the end of the explicit grid
• For determining necessary grid tracks, only contribute the min value
• For placing the item on the grid, if it can span more tracks (up to the max) without impacting the number of tracks or overlapping other explicitly-placed items, let it
• We might consider allowing one-argument span(<integer>) as equivalent to span <integer>

[mirisuzanne]

Agenda+ to see if we can move this forward

[Loirooriol]

Would span(<integer>, <integer>) allow spanning implicit tracks (created by other items)?
If so, it seems that all could do the same? That would be a popular feature (#2402).

[mirisuzanne]

I was expecting we would have to limit this to the explicit grid - primarily for use with repeat(auto-*, …) syntax. I think it would be great if we can solve for both issues, but if the other is significantly more complex, I don't want it to hold this up.

[Loirooriol]

<div style="display: grid; grid-template-columns: repeat(4, auto)">
  <div style="grid-column: span(1, 3)"></div>
  <div style="grid-column: span 1"></div>
</div>

If we place the 1st item with a span of 1, then the 2nd item is placed in column 2, so we won't be able to make the 1st item span more tracks without overlapping.

But since there are 4 columns, I suspect authors would prefer the 1st item to take 3 columns, and place the 2nd item in the 4th column. But this may increase the complexity.

[Loirooriol]

About the syntax, even though span should have been a function (#1137), it may be more consistent to keep it as a keyword, and just accept two integers after it.

Also, the current syntax is span && [ <integer [1,∞]> || <custom-ident> ]. Not sure how <custom-ident> would play with this. Would both the minimum and maximum amounts only consider lines with the provided name? Would each amount accept a different name? And need to be careful if all gets a special meaning.

[mirisuzanne]

If we place the 1st item with a span of 1, then the 2nd item is placed in column 2, so we won't be able to make the 1st item span more tracks without overlapping.

In my proposal, placement would be based on the max (clamped by the available columns). So in this case, the first div would span 3.

[css-meeting-bot]

The CSS Working Group just discussed [css-grid] Ability to clamp track spanning.

The full IRC log of that discussion

<TabAtkins> miriam: especially ins ituation where you use auto-fit/fill repeating grid, there's a pain point where you want element to span multiple columns *if avaialble*, but not add new columns if they're not needed
<TabAtkins> miriam: This is a problem with auto grids, you have to reach for MQ/CQ, figure out the breakpoints, and use that to change the span size
<jensimmons> YYEEEESSSSS This is such a pain to do manually.
<TabAtkins> miriam: There's been many requests for this, been chatting with Elika, wanted to push a proposal for fixing this
<TabAtkins> miriam: Suggest a `span(min, max)` function
<TabAtkins> miriam: so `span(1, 3)` - for the sake of determining what columns are *needed* we use the min, and for the sake of placement we use the max
<TabAtkins> miriam: happy to bikeshed the specifics, but wanted to know if we can start working on it
<TabAtkins> fantasai: in favor generally, i think the syntax is reasoanble
<dbaron> s/placement we use the max/placement we use the max. Could maybe also be an `all` value./
<TabAtkins> fantasai: currently span is a keyword, this would shift it to a function, we could maybe make the second argument optional
<rachelandrew> +1 in general, again something people really would like to do
<TabAtkins> fantasai: one naming concern is that "all" would span only the explicit tracks, not the implicit
<iank_> this adds a bunch of complexity with mansonry, and they willl span a variable amount of columns
<TabAtkins> ???: so in order to determine implicit gridlines you'll use the min span
<TabAtkins> ???: but for placement you use the max - how does that work?
<TabAtkins> miriam: You'd use max, clamped by the number of columns avaiable.
<fantasai> s/???/Ethan/
<fantasai> s/???/Ethan/
<oriol> q+
<TabAtkins> iank_: With the current masonry spec, this makes it... when you place masonry items, they can span variable # of tracks for sizing, that's a somewhat complex interaction
<TabAtkins> fantasai: I think for sizing they'd span the min
<TabAtkins> miriam: I'd also assume that
<TabAtkins> iank_: I don't know if that's correct
<TabAtkins> fantasai: It's a bit awkward for masonry in general. even if you're doing placement, because of the way masonry works you want to palce it into the shortest column, but then you won't bea ble to span anyway
<TabAtkins> fantasai: Some cases where you can, but it's rare - you need similar-height items lining up in rows, and then you probably dont' need masonry anyway
<TabAtkins> iank_: Yeah, for final palcement. But for track sizing, if you're running "place everywhere in ever position", you can have something that'll span 10, then 9, then 8, etc
<TabAtkins> fantasai: That's why when you're calculating sizes, assume it's spanning the min
<TabAtkins> fantasai: Since it'll usually not span more than that
<TabAtkins> Rossen__: we're out of time, let's continue discussing in the issue

[Loirooriol]

I was in the queue to point out that apparently this is not just placing the min, and then growing up to the max after placement, as per #5852 (comment). Also to state what I mentioned in #5852 (comment)

[mirisuzanne]

I'd be happy with a keyword approach rather than a function. I don't have strong opinions on syntax at this point.

I would expect the max span value, as constrained by the total grid tracks available, to take priority in placement. The goal of this feature is not to 'fill the remaining tracks' after placement (I think there's another issue for that) but to span the max tracks without generating additional tracks.