Re: [csswg-drafts] [css-overflow-5] overflow-clip-margin: content-box should not apply border radius to the content box. (#13388)

I'm personally interested in this in the context of nested view transitions where we have an `::view-transition-group-children` element that is currently sized to the element's border box with a transparent border matching the shape and size of the border of the original element. This works and, when clipping, it's the right clip shape and size.

However, when we add non-overlay scrollbars to the original element, I'm unsure if it's at all possible to make an element which matches the clip shape that is produced without reproducing `overflow: scroll`. Note, ideally we'd want to set up an element in such a way that _if it were to clip_ then the clip would match the original element's clip. We do *not* want to set up an element that clips by default (as would be the case with `overflow: scroll`).

Here's an example:

```css
div {
    background: black;
    color: white;
    border-radius: 40px;
    width: 100px;
    height: 100px;
    padding: 1em;
    color: red;
    overflow: scroll;
  }
```

Safari, Chrome:
<img width="150" height="151" alt="Image" src="https://github.com/user-attachments/assets/80c2293a-06e5-4832-adae-d5e0d8b0252d" />

Firefox:
<img width="147" height="152" alt="Image" src="https://github.com/user-attachments/assets/7ebb5de2-730e-4bc4-98bb-2006bf0e4445" />

Notably this is *not* the same shape as the initial clip with `overflow-clip-margin: content-box` with some padding to account for the scrollbars, precisely because of the corner shape. I understand that making content-box be a square shape would also not help here, but I think it's still useful to have a discussion.

Also `scrollbar-gutter` which naively sounds like it should help here, doesn't help. Mostly because it doesn't affect block direction scrollbars and it doesn't seem to affect the clipping area, just reserves the space (maybe that one is a bug though, I'm not sure).

One possibility is to require that the developer clips using `overflow-x/y: scroll`. That gets a bit complicated if the original element had `overflow: auto` meaning the developer needs to first figure out if auto actually caused scrollbars (and optionally if they were non-overlay scrollbars)

Another option which I'd ideally want to avoid is to simply say `::view-transition-group-children` has a magic clip shape that matches the right shape necessary to clip to the same area as the original element. This is bad for obvious reasons: we want to avoid magic

I personally don't know of a solution here, but that of course doesn't mean there isn't one :) Does anyone know how to solve this?


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


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

Received on Monday, 26 January 2026 15:43:47 UTC