Intent to Ship: CSS Corner shaping (corner-shape, superellipse, squircle)

[Noam Rosenthal]

Contact emails

nrose...@chromium.org

Explainer

https://github.com/noamr/explainers/blob/main/corner-shape-explainer.md

Specification

https://drafts.csswg.org/css-borders-4/#corner-shaping

Summary

Enable styling corners, on top of the existing border-radius, by specifying the shape/curvature of the corner. This allows shapes like squircles, notches, scoops etc., and animating between them.

Blink component

Blink>CSS

TAG review

https://github.com/w3ctag/design-reviews/issues/1090

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/823)

WebKit: Support (https://github.com/WebKit/standards-positions/issues/229)

Web developers: Strongly positive (https://www.figma.com/blog/desperately-seeking-squircles)

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes, though some the rendering specific (e.g. color joins and dots) are implementation specific and tested in internal web-tests.
See https://wpt.fyi/results/css/css-borders/tentative/corner-shape?label=master&label=experimental&aligned&q=corner-shape

Flag name on about://flags

CSSCornerShape

Finch feature name

CSSCornerShape

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/393145930

Estimated milestones

Shipping on desktop	139
DevTrial on desktop	136
Shipping on Android	139
DevTrial on Android	136
Shipping on WebView	139

Anticipated spec changes

The base of the spec is quite stable at this point, and is ready to be used by developers. Here is a list of spec issues related to corner-shape:

https://github.com/w3c/csswg-drafts/issues/11623

A shorthand, compatible with current longhands: 
planning to ship this shorthand once the details are resolved, either together with the existing content or in a subsequent release. I believe we can give what's implemented to developers, and add the shorthand a bit later if needed.

* https://github.com/w3c/csswg-drafts/issues/11622

* https://github.com/w3c/csswg-drafts/issues/11679

* https://github.com/w3c/csswg-drafts/issues/12150

These are future compatible enhancements.

https://github.com/w3c/csswg-drafts/issues/11764 

Some rendering questions, but in an area that is implementation defined anyway (color-joins are not interoperable or spec'ed, before corner-shape).

An FPWD for css-borders-4 is underway.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5357329815699456?gate=5559845778096128

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67a0cde5.2b0a0220.164bff.00a8.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Rick Byers]

LGTM1, sounds nice and uncontroversial. Thanks for the spec issues list and analysis! 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYav0x0axtOsPOnOuCVG1BC%2BZMCVpEdzp-cxaV%3DTuHPsOg%40mail.gmail.com.

[TAMURA, Kent]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8NYMVEg7%2BVwmT5yYr28oZhH7EhTwqf1%2B8jB2kjvvazLA%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Domenic Denicola]

LGTM2, and in particular thanks for the clear spec issues analysis.

Probably you should move the tests out of the /tentative/ subdirectory?

[Noam Rosenthal]

On Fri, Jun 13, 2025 at 2:45 AM Domenic Denicola <dom...@chromium.org> wrote:

LGTM2, and in particular thanks for the clear spec issues analysis.

Thanks, it was helpful that you were asking this kind of question in a previous I2S.  

I think this was LGTM3 though? :)

 

Probably you should move the tests out of the /tentative/ subdirectory?

Absolutely, will do that together with the CL that flips the "stable" switch.

 

[Domenic Denicola]

Yep, confirming this was LGTM3, just had a race condition with tkent.

[Alex Russell]

Excited to see this!

Has the TAG weighed in on the proliferation of related but different shorthand syntaxes in this area? We have `superellipse()` here and `cubic-bezier()` in easing. Should we provide both in each system? If not, why not?

Best,

Alex

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8BCL%3DmypdKKO5avobKjRB1d8GpCPgcosHN2w51dzcSPQ%40mail.gmail.com.

[Noam Rosenthal]

On Mon, Jun 16, 2025 at 9:22 PM Alex Russell <sligh...@chromium.org> wrote:

Excited to see this!

Has the TAG weighed in on the proliferation of related but different shorthand syntaxes in this area? We have `superellipse()` here and `cubic-bezier()` in easing. Should we provide both in each system? If not, why not?

There was no such discussion at TAG or at CSSWG.

See https://github.com/w3ctag/design-reviews/issues/1090

Interesting question though, will have a crack at answering it! 

First of all, there is another feature in development (expect an I2P soon) that would allow general purpose bezier curves and any other shapes in borders, called border-shape:
https://drafts.csswg.org/css-borders-4/#border-shape

A superellipse and a cubic bezier are different mathematical formulas, with different purposes. It's possible to approximate a superellipse corner with two or more cubic beziers (that's what the blink implementation does under the hood).

Superellipses are very compelling for corners because they can be divided to 8 symmetrical parts, which means each corner can render two of those curves with their meeting point in the middle.

Also the superellipse spectrum goes between fully concave (notch) and fully convex (square), with several visually interesting points along the way, like a straight diagonal line at k=0, (bevel), round at k=1, and squircle at k=2.

So it's convenient to reason about its values and to animate between them.

A key thing about superellipse-based corner-shapes, unlike the general-purpose bezier-based border-shape, is that because of this symmetry, the corner can curve like a superellipse but still remain "in the corner", retaining symmetry in the middle, while a cubic-bezier can go anywhere...

This allows us to do things with corner-shapes such as supporting the existing border-styles (e.g. dotted) and having different border widths and colors per edge.

This would be much more challenging (not to say impossible) with a general purpose border-shape with cubic beziers - border-shape as currently proposed will not support varied border widths, colors and styles, while corner-shape certainly does.

So this is an explanation of why a superellipse corner-shape can do some things that a general purpose border-shape can't, and vice versa, so they both have room :)

As for using superellipse() in timing functions etc where cubic-bezier() is available, it's certainly possible given enough demand. However, I suspect that the visual subtlety of the superellipse would be lost in a non-visual field like time.

I am not sure if it would add any value there, but if someone asks for it, it can be revisited.

Hope my answer here helps clarify!