- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 31 Mar 2026 18:31:04 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-gaps-1]: Assigning multiple decoration values to flex containers`, and agreed to the following: * `RESOLVED: Adopt linear assignment. Investigate whether to drop the gap coinciding with the break.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> javierct: [shows issue pictures]<br> <TabAtkins> javierct: we ahd a gap breakout recently<br> <TabAtkins> javierct: to recap, several properties that let us declare style/width/color to gap decos as a list<br> <TabAtkins> javierct: for flex specifically, how do we want them to apply<br> <TabAtkins> javierct: assume column-rule-color: red, blue, green, yellow<br> <TabAtkins> javierct: first assumption was that each rule in order cycled those values<br> <TabAtkins> javierct: another possiblity is we reset the count on each line<br> <TabAtkins> javierct: lots of discussion in the issue<br> <TabAtkins> javierct: wanted more feedback<br> <TabAtkins> javierct: i think convo pointed to linear behavior (continuous count across lines)<br> <TabAtkins> javierct: wanted more thoughts<br> <kbabbitt> q+<br> <Rossen> ack kbabbitt<br> <arronei> q+<br> <TabAtkins> kbabbitt: i think all the comments we got on social media were in favor of linear, not per-line reset. happy to resolve on that<br> <fantasai> sgtm, kbabbitt<br> <TabAtkins> linear sounds fine to me<br> <Rossen> ack arronei<br> <TabAtkins> arronei: hm, i was thinking i woudl want reset as a user...<br> <TabAtkins> arronei: if we define it one way someone will want the other<br> <TabAtkins> arronei: could we control it?<br> <miriam> q+<br> <TabAtkins> kbabbitt: we could indeed add a toggle, just use linear by default<br> <Rossen> ack fantasai<br> <TabAtkins> fantasai: one, i'd prefer to avoid a toggle if we can. one more thing to deal with<br> <TabAtkins> fantasai: advantage of linear, if you do want per-line you can often use grid instead<br> <TabAtkins> fantasai: so going with linear for flexbox seems reasoanble, especially if feedback was strong for it<br> <TabAtkins> fantasai: two, if we're going with linear... if you have five items all in one line, gaps are red, orange, yellow, green. If you break between items 2 and 3, is orange gap moved to the next gap or is it dropped?<br> <TabAtkins> fantasai: i feel like you'd want it dropped, so a color association wouldn't break depending on the break point<br> <TabAtkins> fantasai: so aka, if a "gap" is actually a break, we still consume that entry in the gap styling<br> <Rossen> ack miriam<br> <TabAtkins> miriam: i was also gonna say i think there's an advantage to not matching grid, because we already have grid if you need it.<br> <TabAtkins> miriam: i like the linear appraoch<br> <kbabbitt> q+<br> <astearns> “just use grid” … “But I want per-line resets *and* flex sizing!!”<br> <TabAtkins> miriam: i'm a little worried about people trying to corrleate a gap with an item. they aren't actually correlated, if that's what you want you shoudl use a border or something<br> <Rossen> ack kbabbitt<br> <TabAtkins> miriam: but i agree with fantasai that if that's what you want you probably do want to drop at the wrap<br> <TabAtkins> kbabbitt: yeah, style is assigned to the gap itself, not the item... shoudl use a border or something<br> <dholbert> q+<br> <TabAtkins> fantasai: problem is border is never dropped<br> <TabAtkins> fantasai: you still just want to render gaps when actually needed<br> <TabAtkins> fantasai: but maintain the style association<br> <TabAtkins> kbabbitt: i think if you want the deco associated with the item, i'm unsure about th euse-case for dropping it<br> <TabAtkins> fantasai: say you ahve a toolbar, and you ahve sections. first two items are together, next three are togeether. so you want a larger gap between the groups. You make a size pattern that's thin, thick, thin, thin<br> <TabAtkins> fantasai: and if it breaks, you don't want the thick gap to show up in the middle of a group instead<br> <TabAtkins> fantasai: to the extent that we're creating this association and wrapping it, i think we need to maintain that. don't see a reason to not do it<br> <TabAtkins> fantasai: if we were doing line reset model, then yeah, doesn't matter. but since we are continuing across lines, we should keep them associated<br> <TabAtkins> kbabbitt: so you're suggesting that at the end of each line there's a decoaration *assigned* but not painted (since there's no gap)<br> <TabAtkins> fantasai: yes<br> <TabAtkins> dholbert: I'm in favor of linear model.<br> <Rossen> ack dholbert<br> <TabAtkins> dholbert: i see the use-case fantasai is describing but it seems strange to want that behavior....<br> <TabAtkins> dholbert: if i just want these four colors to repeat between my items, and one is missing due to a break, i'm gonna be somewhat confused<br> <alisonmaher> q+<br> <TabAtkins> dholbert: so if a color is associated with each item, sure, it makes sense, but just a pile of flex items with a pile of colors, i think it would be weird if a color gets mysteriously consumed<br> <TabAtkins> fantasai: i think we need to udnerstand better what people want different gap decos for in a flexbox<br> <TabAtkins> fantasai: so we can decide waht they actually want<br> <Rossen> ack alisonmaher<br> <TabAtkins> alisonmaher: +1 to dholbert . if you have the same number of items per line so the same one gets dropped each time, that might be confusing...<br> <TabAtkins> alisonmaher: but we could have it as an opt-in<br> <TabAtkins> fantasai: i'm open to doing whatever behavior but i think we're tlaking a lot in theory here<br> <kbabbitt> q+<br> <Rossen> ack kbabbitt<br> <TabAtkins> fantasai: we've seen demos of how it works, but not real use-cases where authors would acctually want gap decos to repeat in a flexbox<br> <TabAtkins> kbabbitt: i do think having varying decos makes more sense in grid, like separating heading columsn from body<br> <TabAtkins> kbabbitt: we just have to answeer what it means on a flexbox<br> <TabAtkins> q+<br> <TabAtkins> fantasai: right so i think we do need real use-cases for an answer<br> <TabAtkins> arronei: i don't, myself, see myself ever using different colors really<br> <Rossen> ack TabAtkins<br> <fantasai> TabAtkins: I think this is best answered with real-world cases<br> <fantasai> TabAtkins: But also the use-case for grid does indicate that, to the extent that you're varying the decorations, it's a semantic association with the stuff in the grid<br> <fantasai> TabAtkins: other than zebra-striping, often you want to set up different styling based on the content<br> <fantasai> TabAtkins: which suggests to me that we should lean in fantasai's decoration<br> <fantasai> TabAtkins: and assume that if the gaps vary, there is likely to be a semantic association<br> <fantasai> TabAtkins: such that we should maintain that association across breaks<br> <arronei> +1 for more real use case examples<br> <fantasai> TabAtkins: But looking for more legitimate use cases would help answer that question<br> <TabAtkins> kbabbitt: shoudl we just resolve on the issue question - per line vs linear?<br> <TabAtkins> Rossen: that we can do<br> <fantasai> PROPOSED: Adopt linear assignment. Investigate whether to drop the gap coinciding with the break.<br> <fantasai> RESOLVED: Adopt linear assignment. Investigate whether to drop the gap coinciding with the break.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13663#issuecomment-4164597208 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 March 2026 18:31:05 UTC