Re: [csswg-drafts] [css-gaps-1] Clarify if space from content distribution properties consititues a "gutter" for decoration purposes. (#12922)

The CSS Working Group just discussed `[css-gaps-1] Clarify if space from content distribution properties consititues a "gutter" for decoration purposes.`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> oSamDavis: we typically specify the gutter with gap property<br>
&lt;TabAtkins> oSamDavis: but in align-3, extra space from placement properties adds extra space<br>
&lt;TabAtkins> oSamDavis: tension with % insets<br>
&lt;TabAtkins> oSamDavis: with align-content the gutters in a given direction have different widths in a single container<br>
&lt;TabAtkins> oSamDavis: most use of % insets is to achieve the -50% case to join the decos<br>
&lt;TabAtkins> oSamDavis: but that's difficult to resolve when we have varying gutter sizes due to alignment<br>
&lt;TabAtkins> oSamDavis: so we couldn't resolve -50% to any specific value<br>
&lt;TabAtkins> oSamDavis: our proposal, then, is to affirm that alignment does grow gutters, as specified.<br>
&lt;TabAtkins> oSamDavis: but also remove %s entirely, and replace with a keyword that does the "go to the middle" behavior<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: i'm not sure I understood the problem<br>
&lt;TabAtkins> oSamDavis: %s in gap resolve to a fraction of the gap sizejjjjjjjjjjjjjjjj<br>
&lt;TabAtkins> fantasai: in this example (Flexbox) you dont' have a cross intersection. the flex-line rule has to be continuous anyway<br>
&lt;TabAtkins> astearns: I think I might agree with Elika that %s are fine here, but we're already wanting to replace that 50% value with a keyword anyway<br>
&lt;TabAtkins> fantasai: that's fine if you just want to join into the gap, but what if you want *positive* 50%, so it shrinks by half the gap size<br>
&lt;TabAtkins> fantasai: [draws a 4-way intersection]<br>
&lt;TabAtkins> fantasai: 'join' is easy<br>
&lt;TabAtkins> fantasai: but what if you want an inset that's inset the same in all three directions?<br>
&lt;TabAtkins> TabAtkins: oh, you already can't do that. the % is relative to the *other* gap size.<br>
&lt;TabAtkins> fantasai: ah, so only if the gaps are already the same size<br>
&lt;fantasai> TabAtkins: I remember discussing this intersection thing with positive insets<br>
&lt;fantasai> TabAtkins: How wedded are we to flexbox allowing intersections at all on its flex-line rules? It definitely makes things complicated<br>
&lt;fantasai> oSamDavis: We have 1-6, discussed either starting where 2 ends and stopping where 7 ends<br>
&lt;fantasai> oSamDavis: Would have to decide whether we want decoration to span 2 or to span 7<br>
&lt;fantasai> TabAtkins: whether take breaks from line before or line after<br>
&lt;fantasai> fantasai: Asymmetric is bad. If that's what you're looking at, then just don't do it.<br>
&lt;fantasai> iank_: People with wrapping flex boxes you might have one line with a single flex item<br>
&lt;TabAtkins> fantasai: I think you just shoudln't have intersections...<br>
&lt;TabAtkins> oSamDavis: for this case, or flex in general?<br>
&lt;TabAtkins> fantasai: flex in general. the line parallel with flex lines just doesn't have intersections<br>
&lt;TabAtkins> fantasai: if you want a grid, make a grid<br>
&lt;TabAtkins> alisonmaher: this use-case *was* the reason we changed the mental model in the spec from intersections to segments<br>
&lt;TabAtkins> dholbert: defining this to support the general case is def complicated<br>
&lt;fantasai> TabAtkins: Large negative growing into negative space and past that<br>
&lt;fantasai> TabAtkins: at what point does a partial gap on one side extend<br>
&lt;fantasai> TabAtkins: We didn't find a good answer to this<br>
&lt;fantasai> TabAtkins: We've grown past the original issue which was about percentages<br>
&lt;fantasai> astearns: So original question is do we consider flexing space to contribute to the gap measurement<br>
&lt;fantasai> TabAtkins: Even if gaps between 6-7 were small just like 1-2, you'd still create a lot of little squares<br>
&lt;fantasai> TabAtkins: Could still end up with partial overlap<br>
&lt;fantasai> TabAtkins: Fact that they change size isn't fundamental to the issue<br>
&lt;fantasai> fantasai: If those boxes were all random sizes, and didnt align in a grid, what do you expect to happen?<br>
&lt;fantasai> TabAtkins: If we didn't include alignment space, the gutter sizes would all be the same, so we wouldn't have a percentage resolution problem.<br>
&lt;fantasai> TabAtkins: if your inset was zero for this case on the right, with inconsistent alignment spaces<br>
&lt;fantasai> TabAtkins: what does that look like right now with an inset of zero?<br>
&lt;fantasai> oSamDavis: We haven't handled this case for intersections today<br>
&lt;fantasai> oSamDavis: What we were considering was having it between 2 or between 7.<br>
&lt;fantasai> TabAtkins: making it asymmetric<br>
&lt;fantasai> oSamDavis: Each gap creates a start and end point<br>
&lt;fantasai> oSamDavis: So we greedily choose what youre segments would be<br>
&lt;fantasai> oSamDavis: No clear "what to do" here<br>
&lt;fantasai> astearns: I think we take this back to the issue and maybe split out into separate questions<br>
&lt;fantasai> [ discussion of schedules ]<br>
&lt;TabAtkins> yeah, I think the *core* issue (what to do with gaps of different sizes and/or positions on either side) is unresolved, so trying to make a decision about %s in this case isn't very necessary<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12922#issuecomment-3814315400 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 28 January 2026 22:46:40 UTC