This looks like a good feature; can you perhaps clarify the WebKit position? Are they implementing now, or have they just provided support in a standards position? I don't think the difference would sway my vote here, but we should strive for accuracy. If it's the latter, we should also send an FYI to the TAG as we'll be the first to implement.
Also, Dan spotted that this is not marked as being supported on all 6 platforms. Presumably that's an oversight? Best, Alex On Friday, September 18, 2026 at 6:33:46 AM UTC-7 [email protected] wrote: > *Contact emails* > [email protected] > > *Explainer* > https://static.januschka.com/i-425897047 > > *Specification* > https://drafts.csswg.org/css-borders-4/#corner-shaping > > *Summary* > Implements the CSS corner shorthand and per-corner sub-shorthands > (corner-top-left, corner-top-right, corner-bottom-left, > corner-bottom-right) as well as physical (corner-top, corner-bottom) and > logical (corner-block-start, corner-block-end, etc.) edge shorthands. These > allow setting both border-radius and corner-shape for individual corners in > a single declaration. Additionally, corners is retained as a compat alias > for the corner shorthand. sampler: > https://static.januschka.com/i-425897047/ CL: > https://chromium-review.googlesource.com/c/chromium/src/+/7747994 > > *Blink component* > Blink>CSS > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> > > *Web Feature ID* > corner-shape <https://webstatus.dev/features/corner-shape> > > *Motivation* > Currently, setting both the radius and shape of a corner requires two > separate declarations (border-radius and corner-shape). The CSSWG resolved > ( https://github.com/w3c/csswg-drafts/issues/11623#issuecomment-2982179370 ) > to add a corner shorthand that combines both properties, making it more > ergonomic for authors to style individual corners. For example: ```css /* > Before: two declarations needed */ border-top-left-radius: 20px; > corner-shape-top-left: squircle; /* After: single corner shorthand */ > corner-top-left: 20px squircle; ``` > > *Initial public proposal* > https://github.com/w3c/csswg-drafts/issues/6500 > > *TAG review* > *No information provided* > > *TAG review status* > Issues addressed > > *Goals for experimentation* > None > > *Risks* > > > *Interoperability and Compatibility* > *No information provided* > > *Gecko*: Positive ( > https://github.com/mozilla/standards-positions/issues/823) General > standards-position discussion for CSS corner shaping. The corner shorthands > are an ergonomic extension that combines the existing corner-shape and > border-radius properties. > > *WebKit*: Shipped/Shipping ( > https://github.com/WebKit/standards-positions/issues/229) WebKit supports > the underlying CSS corner-shaping proposal. These shorthands combine > corner-shape and border-radius without adding new rendering capabilities. > > *Web developers*: No signals > > *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? > *No information provided* > > > *Debuggability* > *No information provided* > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > No > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > > > *Flag name on about://flags* > *No information provided* > > *Finch feature name* > CSSCornersShorthand > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/425897047 > > *Estimated milestones* > Shipping on desktop 156 > Shipping on Android 156 > Shipping on WebView 156 > Shipping on iOS 156 > > *Anticipated spec changes* > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > *No information provided* > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5152215540039680?gate=4765188386586624 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9a88d4e0-ee44-421d-bbb5-3aab64089854n%40chromium.org.
