Repository navigation
[css-gaps-1] Define how repeated / listed gap-decoration values map to gaps in grid lanes containers #14156
Description
Context
The gap-decoration properties accept value lists, including repeat( <n>, … )
and repeat( auto, … ). For grid and multicol, values are assigned to gaps in a
well-defined order along each axis. For grid lanes containers, the assignment
order along the stacking axis is undefined, because that axis has no shared
lines/tracks and its gutters are misaligned across lanes.
Problem
column-rule-* / row-rule-* lists, and the expansion of repeat( auto, … )
should have mapping onto stacking-axis gutters.
Proposal
- Grid axis. Assign values to track gaps sequentially along the grid axis, as
for grid containers today. - Stacking axis. Assign values in lane by lane order, with each lane being independent
(i.e. the assignment of values in one lane does not affect the others). - Same-item rule. All gap segments belonging to the same item receive the
same value. Specifically, a spanner occupies a single assignment slot (one
value), even though the gutter it owns/interrupts spans multiple tracks.
This same thing applies to the gutters "below" a spanner, even though they are technically not owned by the spanner.
Activity
celestepan commentedon Jul 13, 2026
I'm also curious about how these should look in the case of
fill-reverse-- in your examples, would the red decorations be at the bottom of the container? I think it would make sense for the gap decorations to be reversed along with the items.kbabbitt commentedon Jul 24, 2026
I think it should be consistent with Flexbox.
Having said that, we don't currently reverse the decorations for Flexbox, and that looks wrong to me: https://codepen.io/kevinbcmu/pen/JoEayPO
So I think in both cases, we should reverse them.
css-meeting-bot commentedon Aug 5, 2026
The CSS Working Group just discussed
[css-gaps-1] Define how repeated / listed gap-decoration values map to gaps in grid lanes containers, and agreed to the following:RESOLVED: Colors/styles/etc are assigned independently per track, from placement start.RESOLVED: There's no such thing as a continous rule across lanes, always done per lane even for spanning items.RESOLVED: In flex, grid, and grid lanes, assignment is in placement direction (which may not be writing direction, if reversed)The full IRC log of that discussion
<fantasai> javierct: this is how we assign lists of values<fantasai> javierct: For gird axis, do same as grid containers -- assign values sequentiall
<fantasai> javierct: In the stacking axis, what we propose is assigning values in lane by lane order, with each lane independent
<fantasai> javierct: Example we have red, orange, green, blue
<fantasai> javierct: each lane starts with red, and continues from there
<TabAtkins> q+
<florian> q+
<fantasai> javierct: the spanner gap however occupies a single one
<astearns> ack TabAtkins
<fantasai> javierct: so all of it will be red, even if in 2n column it would be second (not first) rule
<fantasai> [missed]
<fantasai> javierct: We're saying that the spanner's gaps is belonging to the middle gap
<fantasai> TabAtkins: If two spanners, B3 would be green but C3 would be orange.
<fantasai> Example: Add item C2.5 above the spanner. Would above C3 be green or orange?
<fantasai> alisonmaher: I think spanner should reset it
<fantasai> TabAtkins: imagine spanner as the first item across the top
<fantasai> javierct: so we do take into account, above the spanner we have just one gap, we still consider it two gaps for assignment purposes so in third track ...
<fantasai> javierct: So we're saying it would reset it?
<fantasai> TabAtkins: Better way to say it, if spanner looks in startmost track, if something is below a spanner, it just looks at what the preceding rule was regardless of what item generated it
<florian> q?
<fantasai> TabAtkins: so whatever color spanner uses, item following it would use the next color
<fantasai> javierct: I don't feel very strongly ... might be a little weird
<fantasai> javierct: As far as how we define this, wouldn't suffice to say that we do this per lane independently. If we define that way then what we suggest here is strange. So we would need to define it some other way
<fantasai> alisonmaher: Have gaps in different tracks, but owned by same item.
<astearns> ack florian
<fantasai> florian: In terms of what happens after spanner, I agree with what was proposed
<fantasai> florian: But going in other direction, for decoration above the spanner, consider both tracks
<fantasai> florian: Take the max + 1
<alisonmaher> q+
<fantasai> florian: In this case would be orange, because there's at least one red above it
<fantasai> florian: Downside of current is that it repeats. With this idea you'd skip a red and you'd be thing after red
<alisonmaher> q-
<fantasai> TabAtkins: In other cases you'll get repetition. No matter what it can be possible.
<fantasai> florian: Impossible to be perfect.
<alisonmaher> q+
<astearns> ack fantasai
<TabAtkins> fantasai: I think thinking about this has got me rethinking the previous issue
<TabAtkins> fantasai: I think we're creating a problem for ourselves if we're tracking across columns
<TabAtkins> fantasai: when you're painting stuff, if it's per column it's easy, just do it in order
<TabAtkins> fantasai: but if you're leaking info from one column into another, you have to keep track kof the association between an individual spanner and its color
<TabAtkins> fantasai: that requires tracking more info and it's harder to do
<TabAtkins> fantasai: I don't think people will be that excited about this specific behavior
<TabAtkins> fantasai: so in the interest of making the behavior simpler, I think it would be better if the gaps were fully independent
<TabAtkins> fantasai: which would mean splitting the rule over spanners at all times
<astearns> qq+
<TabAtkins> fantasai: that would also give us consistency for rules before/after a spanner, which we currently don't
<TabAtkins> javierct: so even if you did rule-break:none, the spanner's rule won't connect?
<TabAtkins> fantasai: yes. if you want a connected line you have to do the same thing for the top half that you'd use for the top half, which is use a border
<TabAtkins> fantasai: this way you'll get consistent beahvior between the two cases, *and* have a simpler painting algo
<TabAtkins> astearns: the design consideration here is whether the gaps are part of the overall grid, in which case your solution can be reasonable, or if the grid-lanes gaps are really meant to be an item decoration, in which case one of the other proposals can be reasonable
<TabAtkins> astearns: i'm not entirely sure which is closer to author intent
<kbabbitt> q+
<astearns> ack astearns
<Zakim> astearns, you wanted to react to fantasai
<TabAtkins> fantasai: the rules are specified on the container, so there's that
<TabAtkins> fantasai: if the authors wants to associate the rule with the spanner, they probably want it symmetrical on both sides, but we're saying you dont' get that
<TabAtkins> fantasai: so it's a weird inconsistency with rule beahvior depending on being above or below the spanner anyway, which feels uncomfortable
<astearns> ack alisonmaher
<TabAtkins> alisonmaher: I was going to say something similar to Alan
<TabAtkins> alisonmaher: my vision is for a spanner an author *would* want things connected...
<TabAtkins> fantasai: right, but they'd want it for the bottom as well as the top
<TabAtkins> alisonmaher: to florian's point... we can choose different ways each could win, but all cases could have a repeated deco, so we should just go with simpler, which is choose from the first column it spans
<TabAtkins> alisonmaher: you could paint your decos top to bottom, processing each deco for what columns it spans, you'd know the colors... so it's implementable either way
<TabAtkins> florian: also might depend on how long the list of repeated colors might be
<TabAtkins> florian: in my example, the repeats might happen only when your spanners cause you to cycle back to the beginning
<TabAtkins> florian: if it's short, like two alternating colors, we're screwed regardless
<TabAtkins> florian: but it is more accounting
<TabAtkins> alisonmaher: yeah the most common in the stacking axis will probably be one color just because it's so uncontrollable anyway
<TabAtkins> florian: yeah and with elika's proposal it might be "one color, except around spanners where you use borders to do something else"
<TabAtkins> javierct: yeah I see the point. if authors want them connected around spanners, it is weird that we let them do it on one side and not the other
<TabAtkins> javierct: so I could see us just splitting in all cases, which also makes this case easier
<TabAtkins> fantasai: yeah I think it's a simpler, more consistent model
<fantasai> TabAtkins: In that context, in the 4 - 2 -4 case, would we have two rules, on the top and botton of the spanner?
<fantasai> TabAtkins: in the example you have span 4, span 2, span 4
<fantasai> TabAtkins: if we split them all up so we can handle more simply
<fantasai> TabAtkins: wouldn't you get the exact same rules as we see in that final image?
<fantasai> TabAtkins: because if you put 4 split rules along the top item and along the bottom item, you would get two rules in one gap
<astearns> (discussing this example) https://github.com//issues/14153#issuecomment-5133521003
<fantasai> TabAtkins: But if you don't get that then we violate assumption that you can put a rule around the spanner and get something that works
<fantasai> TabAtkins: So not sure there's justification to do it
<astearns> ack kbabbitt
<alisonmaher> q+
<fantasai> kbabbitt: Wrt design consideration vs tying to item vs not
<fantasai> kbabbitt: Similar example for flexbox and toolbar example
<TabAtkins> In the *related* case in Grid, there *are* two gaps between the spanners, because there's an empty grid area between them
<fantasai> kbabbitt: Primitives we have in gap decorations are not built around associating with an item
<fantasai> kbabbitt: The intent right now is just to create patterns
<fantasai> kbabbitt: That points more in that direction
<fantasai> kbabbitt: Splitting decorations across spanning, still processing that idea.
<fantasai> TabAtkins: I don't think it would solve the problem of lines on both sides
<fantasai> javierct: Example you gave with the 3 spanners
<fantasai> javierct: Could you explain again?
<fantasai> TabAtkins: in this case, fantasai's reasoning was to have consistent rule placement on either side of a spanner
<fantasai> TabAtkins: Which means you'd want rule below the first item in all columns
<astearns> ack alisonmaher
<fantasai> TabAtkins: In Grid that would work because we have the track. But in grid lanes we don't have that.
<fantasai> alisonmaher: In that example, only if you get dense-packed itemsw ould you get the rules
<fantasai> alisonmaher: But it would solve some of the other issues
<fantasai> alisonmaher: Either way, that example is a weird edge case
<fantasai> TabAtkins: It does mean our spanners won't have consistent color around it. But we already have inconsistency, so giving up entirely is probably the better idea.
<fantasai> TabAtkins: Although fantasai's proposal doesn't solve the problem she described, still think we should go with it.
<fantasai> TabAtkins: So we would keep resolution to assign per track, and to associate with the following item, but always split
<fantasai> javierct: We're still creating a single gap above item 2 split into 2
<astearns> q+
<fantasai> javierct: guttern to left of 2 is not created by item
<fantasai> TabAtkins: One of the reasons to split up is so that we have symmetrical gap placement on either side of a spanner
<fantasai> TabAtkins: but that would distort model
<fantasai> TabAtkins: so we will get exactly the gaps shown in the diagram, but split the rules in halves/fourths
<astearns> ack fantasai
<TabAtkins> fantasai: in that example, you won't end up with.... because e of the spanner gap situation. but in the more common case the spanner will create a rule above it in all four tracks, and then will be followed by items directly after it.
<TabAtkins> fantasai: so these weird cases with gaps between spanner you won't get the symmetrical behavior, but in the common case (few spanner, mostly span-1 items) you will get (split) lines both above and below the spanners
<astearns> ack astearns
<fantasai> astearns: So we're only ever drawing gap decorations around spanners that are broken up by lanes?
<fantasai> TabAtkins: Rules that cross lanes are not possible. They are always split.
<fantasai> astearns: I've never seen a design where a spanner would emphasize the track divisions
<astearns> ack fantasai
<TabAtkins> fantasai: I agree it's not a typical design pattern
<JohnJansen> +1 to @astearns
<TabAtkins> fantasai: but to get a contiguous line, you have to use a border
<TabAtkins> q+
<TabAtkins> fantasai: we'd talked about having the *top* rule be contiguous, but we'd concluded we can't have it continuous on both sides
<TabAtkins> fantasai: but it's just as common to want it ccontinuous on both sides, or on the bottom
<TabAtkins> astearns: we could say that this is *for* having gap decos on the start side, and if you want them on the other side you use borders
<alisonmaher> q+
<TabAtkins> fantasai: that's werid
<alisonmaher> q-
<TabAtkins> fantasai: if you're drawing rules that are dashed or dotted it won't even be particularly obvious
<TabAtkins> fantasai: but I think this gets us a simpler model, easier to implement, and if you want a continuous line on either side the answer is the same
<TabAtkins> fantasai: (use a border)
<astearns> ack TabAtkins
<fantasai> TabAtkins: The fact that, even with previous continuous behavior, it was only on one side
<fantasai> TabAtkins: There isn't an overwhelming desire to do top side only vs bottom side.
<fantasai> TabAtkins: So it means you can't hit that use case with this anyway, still have to use borders.
<fantasai> TabAtkins: so agree, just use borders.
<fantasai> astearns: We designed gaps because borders weren't capable of drawing into those gaps
<astearns> q?
<fantasai> TabAtkins: It's fine for packing span 1 items. If you do tweird stuff with spanners, you get weird results.
<fantasai> alisonmaher: We dont' have a way to suppress the rules adjacent to a spanner. But we could add it later.
<fantasai> alisonmaher: If an author did that, repeat might get messed up but...
<JohnJansen> future us is going to be mad at past us 🙂
<fantasai> PROPOSED: Colors/styles/etc are assigned independently per track, from placement start.
<fantasai> PROPOSED: There's no such thing as a continous rule across lanes, even for spanning items.
<fantasai> PROPOSED: There's no such thing as a continous rule across lanes, always done per lane even for spanning items.
<fantasai> kbabbitt: We should get author feedback on this.
<fantasai> fantasai: I think authors will say "I want a continuous line on the top or bottom or both, why can't I have it"
<fantasai> RESOLVED: Colors/styles/etc are assigned independently per track, from placement start.
<kbabbitt> q+
<fantasai> RESOLVED: There's no such thing as a continous rule across lanes, always done per lane even for spanning items.
<astearns> ack kbabbitt
<fantasai> kbabbitt: one related thing I noticed, which is that right now in Flexbox when you put decorations between items, we don't follow placement direction
<fantasai> kbabbitt: I'd like to make those two things consistent.
<fantasai> PROPOSED: In flex, grid, and grid lanes, assignment is in placement direction (which may not be writing direction)
<fantasai> RESOLVED: In flex, grid, and grid lanes, assignment is in placement direction (which may not be writing direction, if reversed)
[gap-decorations] Assign flex gap decoration values for reversed flex
[gap-decorations] Assign flex gap decoration values for reversed flex
[gap-decorations] Assign flex gap decoration values for reversed flex
[masonry] Add grid-lanes rule lists WPTs
1 remaining item
[masonry] Add grid-lanes rule lists WPTs
Bug 2065391 [wpt PR 62096] - [gap-decorations] Assign flex gap decora…
Bug 2066180 [wpt PR 62176] - [masonry] Add grid-lanes rule lists WPTs…
[masonry] Assign gap rule values per lane
[css-gaps-1] Define gap decoration value assignment for grid lanes #1…
[gap-decorations] Assign flex gap decoration values for reversed flex
[masonry] Add grid-lanes rule lists WPTs
[masonry] Assign gap rule values per lane
Bug 2065391 [wpt PR 62096] - [gap-decorations] Assign flex gap decora…
Bug 2066180 [wpt PR 62176] - [masonry] Add grid-lanes rule lists WPTs…