Quick correction to this I2S: jsnkuhn caught that the corner shorthands in Chromium still used the earlier per-corner, slash-separated grammar, rather than the current CSS Borders 4 grammar (corner: <'border-radius'> || <'corner-shape'>). The existing WPTs encoded the old grammar too, so passing tests did not catch this. Sorry I missed it before the flag flip.
I reverted the enable CL (https://crrev.com/c/8494091); CSSCornersShorthand is experimental again. The Chromium parser, serialization, and WPT fix is soon under review at https://crrev.com/c/8498274 . The WebKit implementation I mentioned earlier ( https://github.com/WebKit/WebKit/pull/65464) also used the old grammar, behind a default-off flag. I’m preparing a WebKit follow-up as well. Sorry for the churn. I do my best to catch these things, but with the number of moving parts and spec issues involved, mistakes still happen. In the jungle of spec issues, I sometimes lose sight of the trees. is there anything i have to edit on the feature entry to kinda like "halt" it? [email protected] schrieb am Dienstag, 29. September 2026 um 04:23:50 UTC+2: > LGTM3 > On 9/28/26 4:48 p.m., 'Dan Clark' via blink-dev wrote: > > 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 > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/33fe8e41-c8bd-4763-b572-6dca5537570bn%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/bcc3c056-3a1c-4b31-9641-124c81157206n%40chromium.org.
