Repository navigation
[css-gaps-1] Insets instead of outsets #12848
Description
This came up while I was working on spec changes for the resolutions we took in #12024 (comment) and #12603 (comment).
Right now, fine adjustments to gap decoration endpoints are specified as outsets. At the edges of containers, positive values protrude beyond the content edge, negative values recede from it. At interior intersections, positive values protrude into the intersection, negative values recede from it. See the examples starting here: https://www.w3.org/TR/css-gaps-1/#example-74d806b0
The reasoning for representing these as outsets fell out of the fact that column-rule-outset and row-rule-outset each took a single value. I wanted that single value to, by default, do the most commonly wanted thing for a grid: decorations flush with the content edges and continuing through intersections. I achieved that by setting the initial value to 50% and defining the percentage basis to be the crossing gap width at an intersection and 0 at the container edge. (The same examples linked previously illustrate this.)
The key assumptions underpinning that reasoning were negated by the resolutions we took in 12024 and 12603. We will now have separate properties for offsets at edges versus interior intersections, and percentages will resolve with the same basis for both. Given those changes, I think expressing these adjustments as insets rather than outsets would be more intuitive:
column-rule-break: intersection;
column-rule-inset: 0px;column-rule-break: intersection;
column-rule-inset: 5px;column-rule-break: intersection;
column-rule-inset: -5px;column-rule-break: intersection;
column-rule-edge-inset: 0px;
column-rule-interior-inset: 50%;
Activity
jav099 commentedon Sep 25, 2025
Looking at the last example, does this mean that when
insetis set to apxvalue, a positive value means going "in", negative value means going "out", but wheninsetis set to a%, it still relates to the%of the crossing gap (i.e. going "out")?kbabbitt commentedon Sep 25, 2025
Hmm, that's a good point, and a tricky one. It would be really confusing, and likely problematic for things like
calc(), if positive values went "in" forpxand "out" for%. On the other hand, that means the value to reach to the center of the intersection - which would be the initial value for*-interior-inset- would be-50%, which is a little weird.jav099 commentedon Sep 25, 2025
Yeah it's not very intuitive if
pxand%go in different directions. But as you say, negative%is also weird. Perhaps%just doesn't make as much sense now that itsinsets?SebastianZ commentedon Oct 13, 2025
I think it makes sense to introduce an
autokeyword and make it the initial value. It would still compute to0at the edges and to-50%at the intersections, but avoids the awkwardness of negative values for the general use cases.And I'd argue that use cases for negative percentages are very limited besides the initial value and maybe animations from and to that initial value.
And percentages for the edges might refer to the crossing gap width of the first intersection when going inwards. That means, percentages for the interior and edge values would be reflected.
Alternatively, they could be disallowed for the edge values for the time being.
I need to get myself up to date again. Though some years ago I suggested that the lengths of the rules could be defined using percentages, where the percentages would "refer to the length of the gutters".
Not to derail this discussion, though I wanted to note that there are also use cases for letting percentages refer to the content size instead of the gap width.
Sebastian
tabatkins commentedon Oct 14, 2025
It's not problematic for calc() as long as it's defined in a consistent way, where the %s resolve against a negative length. background-position works somewhat similarly, where the % is just resolved against a non-obvious length (container size minus image size).
But I agree that it's confusing and we shouldn't do that. ^_^
kbabbitt commentedon Oct 29, 2025
I believe the resolutions we took in #8402 commit us to making this change. I think an
autokeyword that resolves to0on the edge properties and-50%on the interior properties makes sense.@jav099 could you please incorporate this change into the other updates you're making for the gap decoration outset properties?
[gap-decorations] Parse `*-rule-edge/interior-start/end-outset`
[gap-decorations] Parse `*-rule-edge/interior-start/end-outset`
[gap-decorations] Parse `*-rule-edge/interior-start/end-outset`
[gap-decorations] Parse `*-rule-edge/interior-start/end-outset`
[gap-decorations] Make `column-rule-outset` into shorthand using new …
47 remaining items
Bug 1998483 [wpt PR 55862] - [gap-decorations] Make `row-rule-outset`…
Bug 1998545 [wpt PR 55878] - [gap-decorations] Reintroduce `rule-outs…
Bug 1999318 [wpt PR 55960] - [gap-decorations] Rename `outset` proper…
Bug 1999359 [wpt PR 55962] - [gap-decorations] Rename test files to m…
Bug 1999405 [wpt PR 55967] - [gap-decorations] Rule `inset` propertie…
Bug 1999359 [wpt PR 55962] - [gap-decorations] Rename test files to m…
Bug 1999405 [wpt PR 55967] - [gap-decorations] Rule `inset` propertie…
Bug 1999359 [wpt PR 55962] - [gap-decorations] Rename test files to m…
Bug 1999405 [wpt PR 55967] - [gap-decorations] Rule `inset` propertie…
Bug 1999359 [wpt PR 55962] - [gap-decorations] Rename test files to m…
Bug 1999405 [wpt PR 55967] - [gap-decorations] Rule `inset` propertie…
[css-gaps-1] Update `outset` properties #12603, #12848, #8402 (#13024)
[css-gaps-1] Fix missing syntax for inset #12848 (#13264)