[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.