[css-borders-4] add "radius/corner-smoothing" option to `border-radius` for squircles/superellipse

[jsnkuhn]

https://drafts.csswg.org/css-borders-4/

Idea here is to add sqircles/superellipse as a option for border-radius or a separate property maybe "radius-smoothing" instead of including squircle as a shape option for "corner-shape".

Gives the benefit of being able to be used with corner-shape later to round the corner joints.

round would no longer need to be an option for corner-shape.

This would more closely line up with how vector software and iOS already approach squircles/superellipses

---

Figma's radius-smoothing https://help.figma.com/hc/en-us/articles/360050986854-Adjust-corner-radius-and-smoothing
https://www.youtube.com/watch?v=52pPP4HjieM

Has fine grained control over the smoothing. Also points out that 60 is the corner smoothing value used by iOS.

Swift UI uses "continuous" as a keyword for this: https://developer.apple.com/documentation/swiftui/roundedcornerstyle/continuous

Looks like this is an all or nothing thing in Swift UI. So either all corners are squircle or none are, no ability to mix. (Honestly not sure that I've ever seen an example of say a top right squircle and a bottom left straight round corner though so probably fine?)

Also looks like "continuous" is a binary keyword with no abiity to control the amount of smoothing. Not sure if that would be desirable?

If the main point of squircles in CSS is for things to better line up with SwiftUI's iOS styling than maybe this isn't an issues. Although maybe they change this in the future??

Saw a comment in a YouTube video that said "continuous" might now be the default styling for cornerRadius? Would need to be confirmed.

---

Worth looking into what other vector drawing software might call this. 2 article deepdives:

On a plug-in for adobe illustrator:
https://bootcamp.uxdesign.cc/smooth-corner-rounding-in-adobe-illustrator-94003145a7bf

On implementing smoothing in figma:
https://www.figma.com/blog/desperately-seeking-squircles/

[smfr]

Dup of #6296 ?

[jsnkuhn]

This is an alternate proposal to add the smoothing behavior of squircles as an option to the border-radius property. And therefore not having to add squircle as a keyword to corner-shape which is the purpose of #6296

[didier]

This would make the web feel so much nicer! Consider this my vote.

[mohsen1]

Somehow related:
I tried implementing this with clip-path or image-mask + container queries. Given that I can get width and height of the element using container queries (100cqw and 100cqh) I could potentially compute the path() function's value using a bunch of CSS calc() calculations using width, height and border-radius values. The math to get the Bézier curve is nothing impossible to do with existing CSS functions (sqrt(), sin(), etc)

However:

• path does not support CSS variables in its value
• url (for image-mask`) also does not support CSS variables in the value.

I understand that the value inside of the url() is not computed (for security reasons perhaps?) but would it be possible to let users use CSS variables inside of the path() function? This will unlock almost any shape (dynamically computed) rather than this very specific use-case.

[smfr]

You're asking for the shape() function.

[noamr]

I think this can be closed now?

[jsnkuhn]

#10993 (comment)

So, If I'm reading the resolution here correctly. What has been resolved is to do exactly the opposite of what I am proposing here.

The resolution is to make a "superellipse" keyword for corner-shape instead of adding "corner-smoothing" to border-radius therefor closing the door to later potentially using border-radius to round the joints of the other "corner-shape" options with smoothed circles?

[noamr]

#10993 (comment)

So, If I'm reading the resolution here correctly. What has been resolved is to do exactly the opposite of what I am proposing here.

The resolution is to make a "superellipse" keyword for corner-shape instead of adding "corner-smoothing" to border-radius therefor closing the door to later potentially using border-radius to round the joints of the other "corner-shape" options with smoothed circles?

What are the "other corner-shape options"? corner-shape currently uses superellipses to represent all the proposed corner-shapes. border-radius defines the size of the corner, and corner-shape defines how it is "smoothes" or "shaped".

Can you bring a concrete example of something that's not supported with this?

[tabatkins]

The resolution is to make a "superellipse" keyword for corner-shape

Ah, no, it was to add superellipse() function, with the parameter giving the ellipse exponent (or a scaled version of it). The nice thing about the superellipse shape is that all the major suggested shapes are exactly represented by certain values of the ellipse exponent.

[jsnkuhn]

OK, let me try this: my understanding is the superellipse() function is what the browser vendors will be using behind the scenes to create the different shapes. At the moment, at least, devs would have round, scoop, bevel, notch, straight, squircle options.

I get that this is a working draft and that's probably what's tripping me up a bit here. So I'm guessing that ultimately all the superellipse() function references will only be in the "Interpolating corner shapes" section?

---

This issue piggy backs on a comment put forward by @LeaVerou here
#6980 (comment)

Idea: There are far more use cases for irregular polygons with some rounding on their corners, than for scoop and notch all together. So I wonder if perhaps we need a separate, orthogonal property for the bevel aspect of these corners, with border-radius continuing to apply for their corners.

So there would be a something like this but with notch instead of bevel:

corner-shape:  square square notch square;
corner-size: 0 0 40px 0;
/* A `corner-size` property would be needed to have `border-radius` free to round the joints of each corner */

border-radius:  20px;
corner-smoothing:  ???;
/* The `corner-smoothing` would turn the border-radius rounding into squircle rounding */

[noamr]

I wouldn't implement this shape as a single rectangle with a bottom-right corner setup, but rather as a polygon() with rounded corners or as a shape(). e.g., what if the notch was at the center bottom rather than in the corner? Would we need to invent a new bespoke concept for every shape?

Also, it would be really strange to treat this as a single corner similar to border-radius because it wouldn't work correctly with the text flow.

[jsnkuhn]

Like most devs I implement things in the way I find easiest to do. For example I use border-radius: 50%; for circles even though I'm aware that border-radius was originally only designed for small rounding of corners. I've never used clip-path: circle(); for this even though it's probably the working groups intention.

There will likely be a great amount of overlap between corner-shape use and polygon()/shape(). The most obvious will be the angle 50% for creating a diamond shape and Angled corners of 100% height and a few pixels width will probably be used to make parallelograms.

In all honesty I'm less interested in what something was designed for than what I can do with it.