Re: [csswg-drafts] [css-gaps-1] Gap intersection point definition might need updating for multi-col (#12084)

The CSS Working Group just discussed `[css-gaps-1] Gap intersection point definition might need updating for multi-col`, and agreed to the following:

* `RESOLVED: update definition of gap with gutter terminology`

<details><summary>The full IRC log of that discussion</summary>
&lt;kbabbitt> javierct: as we've defined gap intersections in the sepc currently<br>
&lt;kbabbitt> ... center of an intersection between gap and content edge of container<br>
&lt;kbabbitt> ... or center of an intersection between gaps<br>
&lt;kbabbitt> ... we need to tweak this a little for multicol<br>
&lt;kbabbitt> ... because with spanners, with this definition we would have no intersection where the spanner in multicol meets a gap<br>
&lt;kbabbitt> ... which means we always paint behind the spanner across<br>
&lt;kbabbitt> ... what we want to do is tweak the definition to account for this<br>
&lt;kbabbitt> ... so we can not paint behind the spanner, instead break before and continnue after<br>
&lt;kbabbitt> ... suggestion we floated is twofold:<br>
&lt;kbabbitt> ... 1 tweak the language in spec to define where we define the gap<br>
&lt;kbabbitt> ... to reflect better what multicol does<br>
&lt;kbabbitt> ... so that now that we use gutter in all three, we can update the definition of a gap such that the gap will end when it's in contact with a multicol spanner<br>
&lt;kbabbitt> ... updated definition of a gap would be the center of the start edge and end edge of a gutter<br>
&lt;kbabbitt> ... and the center of an intersection between gaps in different directions<br>
&lt;kbabbitt> ... does imply going back and modifying that bit in the flex spec about the gap<br>
&lt;kbabbitt> oSamDavis: question, are we saying that we aren't ever going to paint behind spanner in multicol case?<br>
&lt;kbabbitt> ... if we tweak the definition but control the break rules<br>
&lt;kbabbitt> ... would it allow us to get the decoration behind the spannert<br>
&lt;kbabbitt> ... with `none` today we get that ability<br>
&lt;kbabbitt> javierct: yes, with `none` we would get that ability<br>
&lt;kbabbitt> ... right now we never paint behind<br>
&lt;kbabbitt> ... with this change we can control whether we want to or not<br>
&lt;kbabbitt> s/right now/right now, with column rules without gap decorations,/<br>
&lt;kbabbitt> oSamDavis: I think the question is, with the change of intersection definition, would we be able to control whether we want to, or never paint behind spanner?<br>
&lt;kbabbitt> ... because having intersection at spanner would mean we never paint<br>
&lt;kbabbitt> javierct: I assumed we would, because we'd have an intersection right before and right after<br>
&lt;kbabbitt> ... so we could control, by saying `none` we would go right through<br>
&lt;kbabbitt> q+<br>
&lt;kbabbitt> oSamDavis: that makes sense<br>
&lt;astearns> ack kbabbitt<br>
&lt;Kurt> kbabbitt: I think the question of whether we can paint behind, I agree the intent is that we should allow paiting behind, we may need to tune wording to allow that. I can't remember if each row of blocks in a multicol.<br>
&lt;Kurt> ...in multicol-2, we're adding the ability to wrap rows of columns, and those rows of columns are considered separate gaps...<br>
&lt;kbabbitt> astearns: is the change to define things in terms of gutters separable from whether we paint behind spanners or not?<br>
&lt;Kurt> astearns: is the change to defining things in terms of gutters separable from the question of whether we paint behind spanners - do we have to solve that?<br>
&lt;kbabbitt> javierct: they're separable, this part of defining things in terms of gutters makes it easer to solve the question in a generic sense<br>
&lt;kbabbitt> ... for multcol this would work for the scenario, woudl also work for other containers<br>
&lt;Kurt> javier: I think defining things in terms of gutters makes things easier to describe in a generic sense, would work for multicol and all containers...<br>
&lt;Kurt> ...they are separate, but they would work together...<br>
&lt;Kurt> astearns: Is the motivation for the change to provide this painting switch, or is it separate?<br>
&lt;alisonmaher> q+<br>
&lt;Kurt> Javier: I would say it's the first, the motivation to make the change to gutter is to generalize painting behavior for gap<br>
&lt;astearns> ack alisonmaher<br>
&lt;Kurt> almaher: is there a distinction between an intersection from a spanner vs a wrapping multicol?<br>
&lt;Kurt> Javier: they are different, you would get an intersection - that doesn't follow with spanners because you wouldn't get a row-gap<br>
&lt;kbabbitt> thank you alisonmaher, that was the point I was trying to get at<br>
&lt;oSamDavis> q+<br>
&lt;Kurt> almaher: so there would be row-gap in between<br>
&lt;Kurt> Javier: our current definition already handles wrapping, because it says a row-gap would form. Spanner is different because it's not like a row gap. That's where it differs from row-gaps in other containers and row gap with wrapping.<br>
&lt;astearns> ack oSamDavis<br>
&lt;Kurt> oSamDavis: Just to also confirm, when you have a spanner, the column gap is two separate gaps in a multi-col. You wouldn't be able to paint behind because they don't belong as the same - even though they look alike, painting behind a spanner wouldn't exist with new defintion<br>
&lt;Kurt> Javier: I guess I'd have to look at it again, because there's an intersection before and after<br>
&lt;Kurt> oSamDavis: but that intersection is before and after the gap, we'd have to paint before<br>
&lt;Kurt> Javier: even with "none", we'd paint behind. But that's the behavior colum rules already have. We'd have to decide to support painting behind the spanner. As now, we'd have to paint behind spanners, which column rules don't currently<br>
&lt;Kurt> ...seems like two different things: give ability to paint behind spanner, control or just paint behind...<br>
&lt;Kurt> ...if we do, maybe we'd need some tweaking, or the other thing, to modify definition so that we're consistent with existing column rules to not paint behind spanner for now...<br>
&lt;Kurt> ...could leave painting behind spanner for later, but would want to be consistent with column rules and not paint behind spanner<br>
&lt;alisonmaher> q+<br>
&lt;Kurt> astearns: makes sense to me to have new stuff match column rule behavior. Not aware of any requests for multi col rules to paint behind spanner, could leave for future. Let's not add complications no one has asked for.<br>
&lt;Kurt> Javier: that's fair, I agree. As far as definition, are we ok with change in gutter naming?<br>
&lt;Kurt> ...if so, that generalizes the problem and solves not painting behind spanner, how are people felling about change in gutter terminology<br>
&lt;astearns> ack alisonmaher<br>
&lt;Kurt> astearns: I'm inclinded to make the change, we have a solution and no alternative suggested<br>
&lt;Kurt> almaher: I agree. If we do decide to not allow painting behind span for multicol, I believe we allow configuring this. We should be consistent w/grid that.<br>
&lt;Kurt> Javier: that's a good point with grid spanners, we do allow that, there might be more tweaking needed<br>
&lt;Kurt> astearns: For now, we can resolve on updating definition of gap with gutter terminology<br>
&lt;Kurt> ...objections?<br>
&lt;Kurt> ...then we are resolved<br>
&lt;Kurt> RESOLVED: update definition of gap with gutter terminology<br>
</details>


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


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

Received on Wednesday, 6 August 2025 15:34:02 UTC