Repository navigation
[css-gaps-1]: Assigning multiple decoration values to flex containers #13663
Description
CSS Gaps 1 proposes that rule style, width and color properties accept multiple values, and that these properties also apply to flex containers. For flexbox, this raises the question of how multiple values should be assigned to gaps in the cross direction (i.e. gap between items).
One option is linear assignment. Here, each gap consumes one value in order. For example, given:
column-rule-color: red, blue, green, yellow;The first gap would use red, the second blue, the third green and so on, cycling as needed.
This model is simple, intuitive, and predictable.
Another option is a per line reset. With this approach, the list of values will be reapplied for each flex line. It sort of comes in handy for cases where gaps may be aligned across different flex lines, and authors might want the same value applied consistently across lines. So rather than having:
We have:
Essentially, the core question here is: should decoration values apply to global cross‑axis gaps, or to per‑line (local) cross‑axis gaps?
My view is that the linear assignment model is more intuitive and straightforward for authors. Flexbox is fundamentally a 1D layout model, and assigning values globally across gaps better reflects that mental model. Resetting values per line risks introducing implicit 2D alignment that flexbox does not guarantee.
Activity
kbabbitt commentedon Mar 16, 2026
I honestly could be swayed either way on this. Would be good to get some more opinions on it.
mhochk commentedon Mar 16, 2026
I lean towards @oSamDavis's recommendation of linear assignment.
Conceptually speaking, having the list reset per line would be treating the lines a lot like rows, when fundamentally the flex container is 1 dimensional.
Practically speaking, flex container doesn't currently offer layout styling options on a per-row basis, though with n-child selectors it effectively offers linear styling that would match this.
jav099 commentedon Mar 18, 2026
Similar to @mhochk and @oSamDavis, I agree that the linear assignment makes the most sense given how Flexbox fundamentally behaves. Moreover, having linear assigment means authors can reasonably predict where a certain color in a list will end up being (i.e they can know that green will be every 3rd item etc), whereas with the resetting approach it would be impossible for authors to determine what color goes between item
nand itemn + 1for a flexbox that is part of a responsive layout. So linear assignment also gives authors more predictable behavior.fantasai commentedon Mar 18, 2026
I think actually I would go with the per-line reset. It's closer to how Grid and Multicol behaves.
css-meeting-bot commentedon Mar 18, 2026
The CSS Working Group just discussed
[css-gaps-1]: Assigning multiple decoration values to flex containers.The full IRC log of that discussion
<hoch> oSamDavis: The width value accepts multiple values. How should they apply to cross-gaps in flex?<hoch> oSamDavis: Option 1 is to go linearly. Option 2 is to reset at every line.
<kbabbitt> q+
<hoch> oSamDavis: I prefer the linear assignment. It's more intuitive. It doesn't require math to figure out the line.
<astearns> ack kbabbitt
<hoch> kbabbitt: My initial reaction was that it would restart for consistency with grid. I can see the argument for it being a linear assignment across the container.
<hoch> kbabbitt: Another thing we should consider is the multi-col behavior.
<astearns> ack fantasai
<hoch> fantasai: I think multi-col should follow the grid model of resetting on every row.
<hoch> fantasai: For flex, the distinction is on the use case. Usually it's "here's a pile of items", but sometimes you use it for a toolbar with particular ordering.
<hoch> fantasai: So I can see use-cases for both.
<hoch> fantasai: So I think we need more input from authors to see which way this should go.
<davidjmarland> q+
<hoch> fantasai: You don't want multi-col to change based on how many columns you ended up with.
<astearns> ack davidjmarland
<hoch> davidjmarland: I do agree with the concept of resetting on every row.
<hoch> davidjmarland: If you had one item offset the gaps, that would make them no longer line up though.
<hoch> <discussion on how this isn't a concern for grid, just for flex>
<hoch> astearns: When Sam Davis originally presented this I though single line would be the normal case. And might associate items with colors. And when you have an unexpected break in the line that would throw it off. But I'm having trouble coming up with a strong position either way.
<hoch> astearns: Could we resolve on resetting per line in all of the layout contexts?
<hoch> astearns: And add a new keyword later if we need to support a linear approach in flex?
<hoch> oSamDavis: I would still lean on the linear approach. If the argument is flex is grid like, I would argue it's fundamentally different.
<hoch> oSamDavis: I don't know about other web devs.
<kbabbitt> q+
<hoch> astearns: I agree, but one of the things we keep hearing is a desire to have per-line control over things.
<hoch> alisonmaher: The most common case is likely 2 colors (e.g. black and white) and resetting could make sense in that case.
<hoch> kbabbitt: If we wanted to add an author toggle in the future based on feedback. Is one behavior or the other easier to achieve backwards compatability?
<hoch> alisonmaher: If we have the same default across all of them that would probably work best. But we could always add an 'auto' or 'normal'.
<hoch> oSamDavis: We can resolve on the per-line reset, and in the future explore making it more global.
<hoch> fantasai: We should ask people to comment on in the main call, and go back to the DevRel team.
<hoch> astearns: So leave this issue open, and come back to it soon for a resolution.
AutoSponge commentedon Mar 18, 2026
Could it be explicit? with a
wrapkeyword or property?astearns commentedon Mar 18, 2026
Yes we can add a switch if needed. But for now we need to decide on the initial default behavior.
mkrause commentedon Mar 19, 2026
I would say the linear assignment model makes the most sense for flex. In terms of mental model flex is a linear list of items, and it seems strange to me if resizing the container would cause certain gaps to change color just based on their wrapping or not wrapping.
Jack-Anstey commentedon Mar 19, 2026
As previous discussion has noted, I think linear assignment is the way to go. It matches conceptually with how flex box generally behaves. I know that if the default behavior where to be per line reset, I think I would be initially confused on why my webpage wasn't rendering as expected. Though, having the switch option as noted by @astearns to enable per line resetting manually would be a good inclusion and a "best of both worlds" option
6 remaining items
ByteEater-pl commentedon Apr 6, 2026
How about this (names free to bikeshed)?
Also
rule-width-at-flex-break,rule-style-at-flex-break,rule-color-at-flex-break, with relevant nonterminals in places of<'column-rule'>and without the final[/ <integer>]?.How would it work?
rule-at-flex-break-skip(initial value: 1; could be 0 if the WG prefers) determines how many virtual rules are consumed by a flex break, i.e. where in the sequence of rules specified by other properties the UA should continue from for internal gaps in the next flex row relative to what would be the case without a flex break. The final the final[/ <integer>], sets it, if present.rule-at-flex-breakis a shorthand for the other four (the remaining 3 in the obvious way). Withnone(initial value), no rules are rendered.beforeandafterallow to render an additional gap with a rule before the flex break, after it, or in both places. The functional variants either specify what rule to use directly, or give offsets with<integer>allowing seeking relative to that rule in the sequence. So,beforeis equivalent tobefore(0)andaftertoafter(0). Resulting (current + specified offset) values, when non-positive or exceeding sequence length, withrepeatpart absent, wrap modulo. If therepeatpart is specified, wrapping occurs only within it once it's entered from the start with a large resulting value, or from the end with a non-positive one. (I assume they're numbered from 1.)The
<integer>inrule-at-flex-break-skipbehaves likewise.Remaining questions:
rule-width-at-flex-breakis unambiguous without/, and the optional could also be placed anywhere. Should there be any relaxation?rule-at-flex-break-skipseem to be 0, 1, 2 and 3. Should it be limited to those, or to non-negative? Should<integer>values inbefore()andafter()be limited to -1, 0, 1, 2? (Given that it seems easy to implement in full generality, I suggest no.)rule-at-flex-break-skip? Inbefore()andafter()? Should two absolute variants be offered: one for the whole sequence, one working just within therepeatpart (skipping to it if not yet reached)? (What if there's norepeatpart?)rule-at-flex-break-skip(and its shorthand after/inrule-at-flex-break) alternatively to<integer>acceptauto(and have it as initial) which would take into account whetherbeforeorafter(lone or functional) are present (resulting in the same behaviour as 1, 2 or 3)?ByteEater-pl commentedon Apr 6, 2026
simplified:
rule-at-flex-break: [none | [before | before([<'column-rule'> | <integer>])] || [after | after([<'column-rule'> | <integer>])] [/ <integer>]?kbabbitt commentedon May 5, 2026
@ByteEater-pl do you have specific use case(s) in mind for something with that degree of flexibility? Not necessarily opposed to it but would like to understand the motivation.
ByteEater-pl commentedon May 15, 2026
@kbabbitt, no additional use cases ATM, mostly just an approach unifying those discussed above. Picking one and leaving no way to do the other things would seem rather arbitrary (unless some use cases are deemed much more important).
I also tried to minimize the complexity surplus. Let you, the WG, be the judges of how well I did.
Even if not all of it goes into Level 1, it can serve as a base for a consistent vision to be realized in some future level.
kbabbitt commentedon Jun 16, 2026
Thanks @ByteEater-pl. We resolved in #13754 (comment) that decorations apply to the actual gaps that exist in multiline flex layout. I opened #14058 to track your suggestion separately.