You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-overflow-3] how do overflow: clip/hidden combinations interact with rounded borders? #7434
css-overflow-3 allows the possibility that 'overflow' is 'clip' in one axis and 'visible' in the other. css-backgrounds-3 says that when 'overflow' is not 'visible', the clipping is done to the curve.
When the computed value of overflow is 'clip' in one axis and 'visible' in the other axis, is clipping done to the curve, nd if so, how?
I'd suggest that perhaps the easy answer is no: if you specify 'clip' in one axis and 'visible' in the other, then 'border-radius' is ignored when clipping.
changed the title [-]how do overflow: clip/hidden combinations interact with rounded borders?[/-][+][css-overflow-3] how do overflow: clip/hidden combinations interact with rounded borders?[/+]on Jun 30, 2022
The CSS Working Group just discussed [css-overflow-3] how do overflow: clip/hidden combinations interact with rounded borders?, and agreed to the following:
RESOLVED: border radius doesn't round the clipping region when mixing overflow: visible and clip
The full IRC log of that discussion
<emilio> dbaron: I missed oriol's last comment, but I think it's relatively simple
<emilio> ... I noticed that the spec allows overflow to be clip in one axis but visible in other axis
<emilio> ... which is something that was introduced when clip was introduced
<emilio> ... when we introduced clip the question is how it interacts with rounding of borders
<emilio> ... I thought the simple question is that you clip in one axis but not on the other border radius has no effect
<emilio> ... oriol posted screenshots, and I'm not sure browsers are doing this new clip and visible behavior
<emilio> oriol: the behavior in browsers is... webkit has a bug where content is not painted... Chromium if it has overflow: visible clip as just clip only with non-zero radius
<emilio> ... so not continuous
<emilio> ... firefox applies the rounded clip to the bounding rectangle of the overflowing content
<emilio> ... In this particular case it looks kind of nice but it can be strange
<emilio> ... I think I'm leaning towards dbaron's proposal
<fantasai> +1 to dbaron's proposal
<flackr> +1 to dbaron's proposal, it makes sense that allowing visible overflow in the off-axis means there's no rounding
<emilio> smfr: I think I agree. The WebKit bug was fixed and now we behave like Chromium but I think that's just bugs, I'm ok with dbaron's proposal
<emilio> proposed resolution is that when clip and visible are specified, border radius has no effect
<fantasai> (on the content)
<fantasai> emilio: what if some corners have no radius and others do?
<dbaron> s/has no effect/doesn't cause rounded clipping of the contents/
<emilio> dbaron: we're not talking about whether border-radius has an effect, but whether it clips the contents
<emilio> ... border-radius with overflow: visible has an effect but doesn't clip
<emilio> ... my argument is that if you're not clipping in one axis you shouldn't clip to the border radius
<emilio> smfr: so basically everything should render as the first Firefox screenshot right?
<emilio> ... is that right if there's no content to clip?
<emilio> smfr: I'd like to see a test-case with something that overflows only on one side but doesn't fill the content box
<emilio> dbaron: I don't think any engine does what the spec says to me
<emilio> dbaron: oh wait, FF does it
<emilio> dbaron: I'll paste a modified test-case in the issue
<emilio> dbaron: https://github.com//issues/7434#issuecomment-1431669370
<emilio> dbaron: I think it should match up with what FF is doing on the later one
<emilio> ... because the inset rules for the clipping cause that to not have any rounding
<fantasai> emilio: I think I'm fine with dbaron's proposal
<fantasai> emilio: could do something more complicated, but unclear it would be useful
<TabAtkins> ok lol i finally looked at firefox's behavior with dbaron's increased overflow, that's silly
<TabAtkins> i see why that would happen but still
<emilio> Proposed resolution: border radius doesn't round the clipping region when mixing overflow: visible and clip
<emilio> dbaron: I should probably clarify that this is just a bugfix in the spec because nobody thought about it
<emilio> ... but I don't think there's any other sensible behavior here
<emilio> smfr: if you look in Firefox at the penultimate box on the last test-case I just posted (where I just shift the box) is that what you're proposing?
<emilio> astearns: so with this resolution we'd still round the border but the overflowing element isn't clipped
<fantasai> fantasai: afaict, all we're proposing here is that the border/background/etc are still rounded as normal, we just don't clip the content to the radius when there's overflow in one axis
<fantasai> (or both axes)
<fantasai> fantasai: this seems fine, what's the confusion?
<emilio> smfr: I just want to confirm that in my latest test-case FF is correct, except for the rounding on the left side
<emilio> dbaron: rithg
<emilio> right*
<emilio> smfr: sounds good
<emilio> +1 as well
<emilio> RESOLVED: border radius doesn't round the clipping region when mixing overflow: visible and clip
Activity
bradkemper commentedon Jun 30, 2022
Your easy answer makes sense to me. Hard to imagine anything else being reasonable or useful.
[-]how do overflow: clip/hidden combinations interact with rounded borders?[/-][+][css-overflow-3] how do overflow: clip/hidden combinations interact with rounded borders?[/+]Loirooriol commentedon Jul 4, 2022
This is what browsers do https://software.hixie.ch/utilities/js/live-dom-viewer/saved/10438
Firefox: the overflowing content gets clipped to its own rounded curve.

Chromium:

overflow: visible clipbehaves asclipif the radius is greater than 0px (so not continuous!)WebKit: bug? The content is not painted at all

smfr commentedon Feb 7, 2023
Recent WebKit versions match Chromium's behavior above.
dbaron commentedon Feb 15, 2023
Here's a modified testcase with a bit more overflow.
smfr commentedon Feb 15, 2023
New testcase: testcase
css-meeting-bot commentedon Feb 15, 2023
The CSS Working Group just discussed
[css-overflow-3] how do overflow: clip/hidden combinations interact with rounded borders?, and agreed to the following:RESOLVED: border radius doesn't round the clipping region when mixing overflow: visible and clipThe full IRC log of that discussion
<emilio> dbaron: I missed oriol's last comment, but I think it's relatively simple<emilio> ... I noticed that the spec allows overflow to be clip in one axis but visible in other axis
<emilio> ... which is something that was introduced when clip was introduced
<emilio> ... when we introduced clip the question is how it interacts with rounding of borders
<emilio> ... I thought the simple question is that you clip in one axis but not on the other border radius has no effect
<emilio> ... oriol posted screenshots, and I'm not sure browsers are doing this new clip and visible behavior
<emilio> oriol: the behavior in browsers is... webkit has a bug where content is not painted... Chromium if it has overflow: visible clip as just clip only with non-zero radius
<emilio> ... so not continuous
<emilio> ... firefox applies the rounded clip to the bounding rectangle of the overflowing content
<emilio> ... In this particular case it looks kind of nice but it can be strange
<emilio> ... I think I'm leaning towards dbaron's proposal
<fantasai> +1 to dbaron's proposal
<flackr> +1 to dbaron's proposal, it makes sense that allowing visible overflow in the off-axis means there's no rounding
<emilio> smfr: I think I agree. The WebKit bug was fixed and now we behave like Chromium but I think that's just bugs, I'm ok with dbaron's proposal
<emilio> proposed resolution is that when clip and visible are specified, border radius has no effect
<fantasai> (on the content)
<fantasai> emilio: what if some corners have no radius and others do?
<dbaron> s/has no effect/doesn't cause rounded clipping of the contents/
<emilio> dbaron: we're not talking about whether border-radius has an effect, but whether it clips the contents
<emilio> ... border-radius with overflow: visible has an effect but doesn't clip
<emilio> ... my argument is that if you're not clipping in one axis you shouldn't clip to the border radius
<emilio> smfr: so basically everything should render as the first Firefox screenshot right?
<emilio> ... is that right if there's no content to clip?
<emilio> smfr: I'd like to see a test-case with something that overflows only on one side but doesn't fill the content box
<emilio> dbaron: I don't think any engine does what the spec says to me
<emilio> dbaron: oh wait, FF does it
<emilio> dbaron: I'll paste a modified test-case in the issue
<emilio> dbaron: https://github.com//issues/7434#issuecomment-1431669370
<emilio> dbaron: I think it should match up with what FF is doing on the later one
<emilio> ... because the inset rules for the clipping cause that to not have any rounding
<fantasai> emilio: I think I'm fine with dbaron's proposal
<fantasai> emilio: could do something more complicated, but unclear it would be useful
<TabAtkins> ok lol i finally looked at firefox's behavior with dbaron's increased overflow, that's silly
<TabAtkins> i see why that would happen but still
<emilio> Proposed resolution: border radius doesn't round the clipping region when mixing overflow: visible and clip
<emilio> dbaron: I should probably clarify that this is just a bugfix in the spec because nobody thought about it
<emilio> ... but I don't think there's any other sensible behavior here
<emilio> smfr: if you look in Firefox at the penultimate box on the last test-case I just posted (where I just shift the box) is that what you're proposing?
<emilio> astearns: so with this resolution we'd still round the border but the overflowing element isn't clipped
<fantasai> fantasai: afaict, all we're proposing here is that the border/background/etc are still rounded as normal, we just don't clip the content to the radius when there's overflow in one axis
<fantasai> (or both axes)
<fantasai> fantasai: this seems fine, what's the confusion?
<emilio> smfr: I just want to confirm that in my latest test-case FF is correct, except for the rounding on the left side
<emilio> dbaron: rithg
<emilio> right*
<emilio> smfr: sounds good
<emilio> +1 as well
<emilio> RESOLVED: border radius doesn't round the clipping region when mixing overflow: visible and clip
Loirooriol commentedon Feb 28, 2023
@smfr My testcase is still broken on latest WebKitGTK.
Do not round the clipping region with mixed overflow clip
Do not round the clipping region with mixed overflow clip
Do not round the clipping region with mixed overflow clip
Do not round the clipping region with mixed overflow clip
Bug 1873102 [wpt PR 43858] - Do not round the clipping region with mi…
Bug 1873102 [wpt PR 43858] - Do not round the clipping region with mi…
Bug 1873102 [wpt PR 43858] - Do not round the clipping region with mi…
Bug 1873102 [wpt PR 43858] - Do not round the clipping region with mi…
Do not round the clipping region with mixed overflow clip
Bug 1873102 [wpt PR 43858] - Do not round the clipping region with mi…