[css-gaps] Gap decoration outsets at the edges

[alisonmaher]

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

[kbabbitt]

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

[kbabbitt]

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

1. we need some way of defining the location where a gap decoration ends at the edge of the container;
2. it would be nice if these container-edge endpoints could be defined so that they work similar to interior endpoints where gaps intersect;
3. 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?

[alisonmaher]

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

[kbabbitt]

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.

[alisonmaher]

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.

[oSamDavis]

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

[kbabbitt]

@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?

[oSamDavis]

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.

[kbabbitt]

@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?