[css-overflow-3] how do overflow: clip/hidden combinations interact with rounded borders?

[dbaron]

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.

(Noticed while trying to write edits for #6212.)

[bradkemper]

Your easy answer makes sense to me. Hard to imagine anything else being reasonable or useful.

[Loirooriol]

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 clip behaves as clip if the radius is greater than 0px (so not continuous!)
  

• WebKit: bug? The content is not painted at all
  

[smfr]

Recent WebKit versions match Chromium's behavior above.

[dbaron]

Here's a modified testcase with a bit more overflow.

[smfr]

New testcase: testcase

[css-meeting-bot]

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

[Loirooriol]

@smfr My testcase is still broken on latest WebKitGTK.