[css-gaps] Gap decoration outsets at the edges

@kbabbitt

In the CSS Gap Decoration spec, percentage-based gap outsets are resolved to 0 at the edges.

This makes sense to me, although I'm wondering for other kinds of outset values, if an author still might want to have the outset at the edge different than all other intersection points. The main case I could see is whether an author wants this to match other outsets, or always compute to zero at the edges.

Given this, perhaps we could add an optional input to the *-outset properties that indicates whether the outset is applied to the edges.

Something like rule-outset: 5px exclude-edges, where the default is include-edges (or perhaps exclude-edges would make sense as the default). And exclude-edges would mean that the outset is treated as 0 at the edges, instead of what is specified by the author.

CC @kbabbitt

Finer control over outsets also showed up in Explainer feedback: MicrosoftEdge/MSEdgeExplainers#996

So I suppose the way I was thinking about it is:

we need some way of defining the location where a gap decoration ends at the edge of the container;
it would be nice if these container-edge endpoints could be defined so that they work similar to interior endpoints where gaps intersect;
that could be achieved by treating the container edges as if they were "zero width gaps" so to speak

The "percentages resolving to 0 at the edges" behavior fell out of point 3. Perhaps it would make things clearer to define those zero-width gaps explicitly? That would also give us a tool to address #12084.

Also, on the use case for exclude-edges vs include-edges: Were you thinking of something similar to what's in explainer issue 996 linked above? Or did you have something else in mind?

I suppose the use case I was thinking of could handled by issue 996.

The main case I was thinking of was if you want to adjust outsets everywhere but at the edges, such that the decorations are always flush with the edge, but take the outset into account at all other intersections.

I'm not sure if there is an author need for this, but it came to mind when reviewing some of the wpt tests for the feature where the decoration overflowed the edges as a result of the outset, and I figured that is unlikely to be a desirable behavior. See https://chromium-review.googlesource.com/c/chromium/src/+/6341671/19/third_party/blink/web_tests/external/wpt/css/css-gaps/tentative/grid/grid-gap-decorations-012.html as an example

I'm not sure if there is an author need for this, but it came to mind when reviewing some of the wpt tests for the feature where the decoration overflowed the edges as a result of the outset, and I figured that is unlikely to be a desirable behavior. See https://chromium-review.googlesource.com/c/chromium/src/+/6341671/19/third_party/blink/web_tests/external/wpt/css/css-gaps/tentative/grid/grid-gap-decorations-012.html as an example

One use case I had in mind for decorations extending outside the bounds of the container is something like #2748 (comment):

I envisioned constructing this by doing something like:

.container {
  display: grid;
  grid-template-columns: 400px 100px;
  row-gap: 10px;
  row-rule: 1px solid silver;
  row-rule-outset: 10px;
  margin: 10px;
}

such that the decorations extend into margins on the grid. Though if that would be considered weird, I suppose authors could achieve the same effect with padding on the grid items instead.

Thanks for the example, that does feel like a plausible authoring use case, and I think this is a valid use case to support. (This case would be covered by include-edges).

When there is more than one colum, though, like in https://chromium-review.googlesource.com/c/chromium/src/+/6341671/19/third_party/blink/web_tests/external/wpt/css/css-gaps/tentative/grid/grid-gap-decorations-012.html, I'm wondering if there are cases where an author would want to apply a larger outset everywhere but the edges. Maybe not, but if so, I don't think there is a way to achieve that currently (unless an author were to use percentages).

Perhaps the suggestion in 996 could help with that, though.

Commenting on this issue because I agree that authors might find it useful to have finer control over *-rule-outset and *-rule-break behaviors. Similar to the width, style and color syntax which allow authors target specific gaps, I think authors might want different rule-break and rule-outset behaviors for different gaps. I've put together a couple of examples to shed more light on this.

The first is the classic periodic table design layout (inspired by work done by Brett Jones). In this layout, it would be beneficial not only to assign different outset behaviors to each gap, but also target each intersection end individually for those outsets. Below I've sketched how each column gap might have its own outset behavior:

For different breaks, consider the case (Testcase inspired by Patrick Brosset):

Right now row-rule-break is set to intersection. What I’d like is the ability to make the first, second, and last row gaps non‑breaking, while the middle gaps break at every intersection.

row-rule-break: none none repeat(auto, intersection) none
row-rule-outset: unset unset repeat(auto, 0) unset

@oSamDavis

@oSamDavis thanks for the examples. In the periodic table, I noticed that the first decoration doesn't extend all the way down but stops one item short. Is that part of what you're looking for, and if so do you have any thoughts on how an author might set that?

Yes, I envision authors being able to specify both the “start” and “end” outset for each decoration segment, using a slash‑separated pair perhaps. For example, the periodic table example might have a configuration like:

column-rule-break: none;
column-rule-outset: 0 / -30px, 0, repeat(3, -30px / 0), repeat(auto, 0)

Each start / end pair controls how far the decoration extends from the segment’s leading and trailing edges.

@oSamDavis

@oSamDavis I think Gap Decoration Areas might be a better fit for the periodic table case. The advantage there would be that the decoration starts/ends/break behaviors could be set relative to the grid layout, which I think would respond better to changes compared to using px offsets which would need to be kept in sync with the item sizes. WDYT?

The CSS Working Group just discussed [css-gaps] Gap decoration outsets at the edges, and agreed to the following:

RESOLVED: percentages resolve to the same value for edges vs. interior decorations
RESOLVED: Two longhands to set inner/outer outsets, names at editor discretion
RESOLVED: The shorthand lists inside first

The full IRC log of that discussion

<fantasai> kbabbitt: This is exactly the case, where an author might want to control the gap decorations differently at edges of container vs interior
<fantasai> kbabbitt: there was suggestion to set only interior using a switch
<fantasai> kbabbitt: but separate setters might be way to handle it
<fantasai> kbabbitt: another idea was being able to specify list of values, similar to alternating colors
<fantasai> kbabbitt: question is how do we want to handle this case?
<emilio> fantasai: most common case when you're going to want outsets you're going to have interior outsets different from the outer ones
<emilio> ... inner ones 50%, outers 0
<emilio> ... I think that's common
<emilio> kbabbitt: for the interior intersection the basis the width of the gap in the cross direction
<SebastianZ> q+
<emilio> ... for the exterior is 0
<emilio> fantasai: I think that's not what you want to do
<emilio> ... percentage basis should be same for both
<emilio> ... if you want 25% on each side for the interior
<emilio> ... you want the outer gap to not flush, but be the same amount
<emilio> ... if you'd use an absolute value you'd get the outset on both interior and exterior
<emilio> ... if you switch to percentages we shouldn't change that
<emilio> ... what you want to do is to split it into inside/outside
<emilio> ... rule-outset-inside/outside
<emilio> ... that way you can set the outset for just the interior e
<emilio> alisonmaher: rule-outset-edge?
<emilio> fantasai: whatever, inner/outer...
<emilio> ... but I think that'd give you the control you want
<emilio> alisonmaher: the list approach would work...?
<emilio> fantasai: no because you need to track the repeat
<emilio> alisonmaher: if you are autorepeat you could
<emilio> fantasai: you don't know how many columns you want with auto repeat
<emilio> ... repeat might be useful for pattern-like thing
<emilio> ... but for the exterior one you don't know how many columns you have
<emilio> astearns: we've used positive / neg indices
<emilio> ... if you want to target ends
<emilio> ... not sure that's the right design here
<emilio> kbabbitt: we have auto repeat for widths/colors to fill gaps not specified
<emilio> ... but I agree in this case is edges vs. interior
<astearns> ack SebastianZ
<emilio> ... and we should design it that way
<emilio> SebastianZ: you lost me a bit
<emilio> ... but reading the minutes I think we agree on what I had in mind
<emilio> ... so having different outsets for interior and edges
<emilio> ... so we can control it differently
<emilio> ... maybe we could resolve on that?
<emilio> kbabbitt: yeah wonder if we could resolve on this
<emilio> fantasai: we need 2 resolutions
<emilio> ... one that percentages resolve to the same value
<emilio> RESOLVED: percentages resolve to the same value for edges vs. interior decorations
<emilio> PROPOSED: rule outset has two longhands, one for interior one for exterior
<emilio> fantasai: interior one could be split up faster
<emilio> s/faster/later
<emilio> emilio: exterior as well theoretically right?
<emilio> SebastianZ: do we want to resolve on names?
<fantasai> interior vs exterior is much more likely to be distinguished than start vs end
<kbabbitt> rule-edge-outset / rule-interior-outset ?
<fantasai> and to be set independently
<emilio> fantasai: I think you want outset so that the shorthand is prefixed
<emilio> SebastianZ: I wouldn't call it outset
<emilio> ... the outset can still be an inset
<emilio> fantasai: but that's an inset
<kbabbitt> rule-outset-edge / rule-outset-interior
<emilio> ... negative
<emilio> ... default direction is out
<emilio> fantasai: should we go with interior vs. exterior?
<emilio> astearns: I prefer edge
<emilio> fantasai: less parallel
<emilio> SebastianZ: I'd prefer inner / outer
<emilio> ... interior / exterior might be difficult
<emilio> astearns: rule-outset-{inner,outer}?
<emilio> PROPOSED: Two longhands to set inner/outer outsets, names at editor discretion
<emilio> RESOLVED: Two longhands to set inner/outer outsets, names at editor discretion
<emilio> fantasai: the shorthand needs to set both, should it be inner outer or outer inner?
<emilio> alisonmaher: one value applies to both
<emilio> fantasai: but if you specify both should it be inside then outside or vice versa
<emilio> SebastianZ: gut feeling says inside then outside
<emilio> fantasai: let's go with that
<emilio> RESOLVED: The shorthand lists inside first

Draft edits for resolutions in w3c#12024

RESOLVED: Two longhands to set inner/outer outsets, names at editor discretion

For the record, we currently have three suggestions for name pairs

interior and edge
inner and outer
inside and outside

I slightly prefer option 3, because we already have several other properties with those suffixes like shape-inside and shape-outside, break-inside, and wrap-inside. And while we do have some properties with edge in their name, there's no corresponding interior. Plus, interior seems to be a relatively uncommon word.

Sebastian

Navigation Menu

Repository navigation

[css-gaps] Gap decoration outsets at the edges #12024

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-gaps] Gap decoration outsets at the edges #12024

Description

Activity

kbabbitt commented on Apr 21, 2025

kbabbitt commented on May 2, 2025

alisonmaher commented on May 2, 2025

kbabbitt commented on May 2, 2025

alisonmaher commented on May 3, 2025

oSamDavis commented on Jul 18, 2025

kbabbitt commented on Jul 18, 2025

oSamDavis commented on Jul 18, 2025

kbabbitt commented on Jul 25, 2025

css-meeting-bot commented on Aug 20, 2025

SebastianZ commented on Oct 28, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions