LGTM2 On Monday, September 28, 2026 at 4:48:32 PM UTC-7 [email protected] wrote:
> Thanks for the update. LGTM1. > > On Thursday, September 24, 2026 at 3:12:33 AM UTC-7 [email protected] > wrote: > >> ok was faster than i thought, the webkit PR >> https://github.com/WebKit/WebKit/pull/65464 landed (behind flag) >> >> Am Mi., 23. Sept. 2026 um 18:10 Uhr schrieb Helmut Januschka < >> [email protected]>: >> > Updated the entry and changed WebKit's status to "In development.". >>> Sorry again about the missing platforms checkmark, I filed three entries >>> around the same time and missed it on all of them. >>> >>> WebKit's position on the underlying corner-shaping proposal is positive: >>> https://github.com/WebKit/standards-positions/issues/229 >>> >>> There is an open WebKit PR that importet tests: >>> https://github.com/WebKit/WebKit/pull/74191 >>> >>> I also started an implementation. The PR is a bit outdated, but I'll >>> revive it in the next few days: >>> https://github.com/WebKit/WebKit/pull/65464 >>> >>> I don't know what the WebKit timeline would be, though. >>> >>> Am Mi., 23. Sept. 2026 um 17:12 Uhr schrieb Rick Byers < >>> [email protected]>: >>> >> Looks, like it is implemented on all blink platforms and the WebKit >>>> position is 'support' but not 'shipping'. Right Helmut? >>>> >>>> I'm happy to approve once the chromestatus entry is corrected. >>>> >>>> On Mon, Sep 21, 2026 at 11:46 AM Alex Russell <[email protected]> >>>> wrote: >>>> >>> 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 >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9a88d4e0-ee44-421d-bbb5-3aab64089854n%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- 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/33fe8e41-c8bd-4763-b572-6dca5537570bn%40chromium.org.
