Re: [csswg-drafts] [css-gaps-1] `overlap-join` with `between` rule visibility (#13697)

> RESOLVED: Trim the unjoined segments. TBD how exactly that should work.

@oSamDavis @jav099 @alisonmaher @mhochk and I had a long discussion on the "TBD" this morning. The biggest challenge we ran into is: What should we specify *today* to put us on the right path to a *future* level of Gap Decorations that affords more author control over join behaviors?

## Recap of current state

Per the spec, we have eight [inset property longhands](https://drafts.csswg.org/css-gaps-1/#inset), consisting of the various combinations of `[column|row]-rule-[edge|interior]-inset-[start|end]`.

In practice, I expect approximately no one other than WPT authors will use these longhands. Instead, they will use shorthands to achieve the effects they want:

* [`[column|row]-rule-inset`](https://drafts.csswg.org/css-gaps-1/#insets-universal) to set all insets uniformly in the column or row direction, or both directions simultaneously.

* [`[column|row]-rule-inset-[start|end]`](https://drafts.csswg.org/css-gaps-1/#insets-start-end) to set start and end offsets separately, to achieve an asymmetric separator effect.

* [`[column|row]-rule-[edge|interior]-inset`](https://drafts.csswg.org/css-gaps-1/#insets-edge-interior) to achieve different treatments at edge versus interior intersections.

The initial value for all inset properties is 0. We [resolved](https://github.com/w3c/csswg-drafts/issues/13137#issuecomment-3814256054) on that at the January F2F.

One issue that came out of that discussion is that it should still be easy for authors to specify that they want decorations to join at T and corner intersections. They can achieve this with [`calc()`](https://github.com/w3c/csswg-drafts/issues/13137#issuecomment-4001141976) to a degree, but it's not very author-friendly and not feasible with decorations of varying widths. So during the Gaps breakout call in mid-March, we [resolved](https://github.com/w3c/csswg-drafts/issues/13137#issuecomment-4083588421) to add the `overlap-join` keyword to achieve joining behavior.

Last week at the April F2F, we reached the resolution at the top of this comment: unjoined segments should not be affected by `overlap-join`. Simple enough on its face, but it sparked further discussion on what the right pivot points should be for insets in general and joining vs dangling ends specifically.

That led us to today's discussion, in which a few different paths forward surfaced. Again, **these are sketches of future levels of the spec, to help inform the direction we should take now**. For Level 1, I don't think we should bake in any more features beyond the single toggle we resolved on that allows authors to achieve joins without having to rely on calc().

All names in the examples below are subject to bikeshedding.

## Option 1: Move join behavior to a separate property

#### Level 1

```css
*-rule-*-inset-*: <length-percentage>
rule-intersection-join: [ none | overlap ]
```

Simple toggle. If the decoration end adjoins an intersection with one or more other decorations, stretch into an overlap-join; otherwise apply the inset.

#### Future possibility
```css
*-rule-*-inset-*: <length-percentage>
rule-intersection-join: [ none | overlap | abutment ] <length-percentage>?
```

The optional `<length-percentage>` on `*-rule-intersection-join` would further offset from the keyword effect, for example allowing authors to achieve a "near abutment" effect where the decoration protrudes into the intersection without actually touching other decorations.

#### Advantages

Avoids further exploding the `*-rule-*-inset-*` property/value space.

#### Drawbacks

Draws a boundary around the flexibility we could expose to authors in the future. I think this is, essentially, a boiled-down version of Option 3.

The way to achieve an abutment join is not clear. If there are separate `column-` and `row-` variants of `rule-intersection-join` then an abutment would require you to specify `overlap` on one and `abutment` on the other to indicate which abuts the other, which is a bit of a wart. Or we could have `row-abuts-column` and `column-abuts-row`.

## Option 2: Supply join and not-join behaviors together on the inset properties

There are a couple of variations on this theme:

### 2a. Function for join vs non-join behaviors

#### Level 1

```css
*-rule-*-inset-*: <length-percentage> | overlap-join
```

If the decoration end adjoins an intersection with one or more other decorations, stretch into an overlap-join; otherwise apply the inset.

#### Future possibility

```css
  *-rule-*-inset-*: <inset-value>
  <inset-value> =   <length-percentage>
                    | overlap-join   /* = if-intersecting(overlap 0px, 0px) */
                    | abutment-join  /* = if-intersecting(abutment 0px, 0px */
                    | if-intersecting([abutment | overlap]? <length-percentage>, <length-percentage>);
```

The `if-intersecting()` function applies the first value in cases where a decoration end adjoins an intersection with one or more decorations, the second value in other intersections. The optional `[abutment | overlap]` keyword changes the reference point for the `<length-percentage>` from "edge of the intersection" to "near edge of the crossing decoration" or "far edge of the crossing decoration" respectively.

#### Advantages

More flexible than Option 1; gives authors control over decoration lengths both in cases where decorations intersect each other and where they're left dangling.

#### Drawbacks

Not as cascade-friendly as separating intersecting and non-intersecting behaviors into their own properties. Forces authors into a complex functional notation if they want join behavior at applicable intersections and inset behavior at other intersections.

### 2b. Instead of eight longhands, a single extensible `rule-inset` property

We didn't fully flesh this one out, but roughly it would be:

```css
  rule-inset: <inset-spec>#
  <inset-spec> = [ [ interior | exterior ] || [ start | end ]
                   || [ row | column ] || [ intersecting | dangling ] ]? <length-percentage>
```

Missing from the straw grammar above: selection of overlap or abutment join behavior.

In this model, authors would define their inset behaviors with a single property. Values with various combinations of keywords apply to all endpoints that match those keywords; for a given endpoint the last applicable value wins.

Example:
```css
  /* Apply an inset of 0px to all endpoints except column starts which are 5px */
  rule-inset: 0px, column start 5px;
```

#### Advantages

Limits the explosion of additional properties as we discover more ways authors want to apply differing insets.

#### Drawbacks

Even less cascade-friendly. Not clear that selection of overlap or abutment join behavior would integrate cleanly into the grammar: it would be useful for the "intersecting" properties but a no-op (or invalid?) for the "dangling" properties.

## Option 3: Change the edge|interior distinction to intersecting|dangling

This is similar to @mhochk's previous suggestion, except using the terms "intersecting" and "dangling" to avoid confusion about the endpoints inside the "donut hole" in my reaction comment.

#### Level 1

```css
[column|row]-rule-[intersecting|dangling]-inset-[start|end]: <length-percentage> | overlap-join
```

#### Future possibility

```css
[column|row]-rule-[intersecting|dangling]-inset-[start|end]: <length-percentage> [ overlap-join | abutment-join ]
```

#### Advantages

Achieves flexible distinction between intersecting and non-intersecting decorations in a cascade-friendly way, without further increasing the number of properties in Level 1.

#### Drawbacks

We might need to add back the edge|interior distinction later, especially if we pursue the author suggestion in #13087 to allow for gaps & decorations around the edges of a container. If that happens, that would bring us up to *sixteen inset longhands* which exist only to allow for the various permutations authors might *actually* want. We might also find ourselves needing to shorthandify some of our L1 properties, which runs into the issues discussed in #8398. Also runs into the same issues as Option 1 with regard to achieving an abutment join.

-- 
GitHub Notification of comment by kbabbitt
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13697#issuecomment-4195580317 using your GitHub account


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

Received on Monday, 6 April 2026 23:36:07 UTC