[csswg-drafts] [css-overflow] Understanding the shape of the clip with scrollbar-gutters (#13407)

vmpstr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-overflow] Understanding the shape of the clip with scrollbar-gutters ==
### A bit of background and context:

We have a view transition nested groups feature, which allows us to construct nested pseudo element groups in the view transition pseudo tree.
```
::view-transition-group(foo)
  ::view-transition-image-pair(foo)
    ::view-transition-old(foo)
    ::view-transition-new(foo)
  ::view-transition-group-children(foo)
    ::view-transition-group(bar)
    ...
```

This is very useful if a view transition is running on an element (scoped view transitions), because we have agreed at TPAC that by default participating elements within the scope are not clipped by the scope. This means that by default, inner participating elements would pop out of the clip during the transition and pop back in afterwards.

This is fine, that's what we have nested view transition groups for. We can construct the above structure so that the scope element (foo) can still clip the inner participating element (bar). This is done by putting a clip on `::view-transition-group-children(foo)`.

Now the question is what is the shape of this clip? Well, again by default, it is the same size as `::view-transition-group(foo)`, which in turn is the same size as the border box of the "original" element (the one with `view-transition-name: foo`). It also has default styles of the same border width and shape as the original element, except that the border is transparent. We **don't** by default add `overflow: clip` or anything like that, but the idea is that from the developer's perspective "it's as easy as adding `overflow: clip`" if that's required (after all the original element may also not be clipping, or we at least don't care if it does).

### What the problem is:

The problem that is hard for me to solve is when the original element (the one with the `view-transition-name`) has overflow: scroll or overflow: auto with classic scrollbars. The shape of the clip caused by this is roughly the shape of the padding box with a bit of rectangular inset to account for the classic scrollbar. That is also, not interoperable right now. As I mentioned in https://github.com/w3c/csswg-drafts/issues/13388#issuecomment-3800277711, here's what it looks like to have a div with rounded corners (on all corners) and a classic scrollbar.

Chrome, Safari:
<img width="146" height="153" alt="Image" src="https://github.com/user-attachments/assets/a33f7bed-28d6-41eb-9979-3474e3682e38" />

Firefox:
<img width="145" height="150" alt="Image" src="https://github.com/user-attachments/assets/fba2e903-07f5-4ae4-9d0b-905c758c5c97" />

I am hoping that someone knows what we should be doing here in terms of spec. Personally, I like the way Firefox behavior looks visually. I *think* this is covered by https://www.w3.org/TR/css-backgrounds-3/#corner-overlap, specifically

> If the curve interferes with UI elements such as scrollbars, the UA may further reduce the used value of the affected border radii (and only the affected border radii) as much as necessary, but no more.

So in order for us to reproduce this shape in `::view-transitions-group-children`, I'm not sure what we could do especially since we don't want to actually *have* the clip just have the shape of it if the developer adds `overflow: clip` or whatever.

### scrollbar-gutter

One potential solution I can see here would be somewhere in the space of [`scrollbar-gutter`](https://drafts.csswg.org/css-overflow-3/#scrollbar-gutter-property). My naive understanding of it is that this property allows you to reserve some space in such a way that if a classic scrollbar did appear, it would not shift the content area and thus not require us to reflow the contents.

There are some issues however:

1. It requires a clip. Emphasis mine:

> The [scrollbar gutter](https://drafts.csswg.org/css-overflow-3/#scrollbar-gutter) is present for [classic scrollbars](https://drafts.csswg.org/css-overflow-3/#classic-scrollbars) **_when [overflow](https://drafts.csswg.org/css-overflow-3/#propdef-overflow) is [hidden](https://drafts.csswg.org/css-overflow-3/#valdef-overflow-hidden), [scroll](https://drafts.csswg.org/css-overflow-3/#valdef-overflow-scroll), or [auto](https://drafts.csswg.org/css-overflow-3/#valdef-overflow-auto)_**, regardless of whether the box is actually overflowing. [Overlay scrollbars](https://drafts.csswg.org/css-overflow-3/#overlay-scrollbars) do not consume space.

It would be nice if it didn't, or maybe have some value that allows us to have the scrollbar gutter independent of the overflow property. That would make it possible to use in view transitions.

2. There is no way to specify a gutter at the block-end side of the box. 

This is understandable for the use-case that this is solving, but I assume we can add a new value that would allow the block-end side scrollbar gutter space to be non 0? I don't know of an implementation reason that this would be hard.

3. The shape doesn't seem to be specified well

Chrome (which I think is a bug):
<img width="150" height="143" alt="Image" src="https://github.com/user-attachments/assets/52013aa2-4c6b-4542-bedf-2bb9215be927" />

Safari:
<img width="149" height="147" alt="Image" src="https://github.com/user-attachments/assets/f5448ee2-2780-4b87-8bde-76d3e1c4cff8" />

Firefox:
<img width="148" height="149" alt="Image" src="https://github.com/user-attachments/assets/8c8862e7-25bb-4c29-8769-84d4e2e7b934" />

Between https://github.com/w3c/csswg-drafts/issues/13388, https://www.w3.org/TR/css-backgrounds-3/#corner-overlap, and https://drafts.csswg.org/css-overflow-3/#scrollbar-gutter, I can't find an explanation for why the shape of this clip should be any different from roughly specifying some `padding` (and clipping to the content-box). It doesn't seem like it allows for reducing the radii or for not respecting the corner shape.

I think we should fix that and change the wording to allow for the shape to remain as it is today (roughly the same as if you had classic scrollbars except those are not painted or whatever).

/cc @flackr 


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13407 using your GitHub account


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

Received on Wednesday, 28 January 2026 20:33:48 UTC