Hi Alex, The main pattern this serves is the “circular reveal”, animating clip-path: circle() so the circle fully covers its box. The required end radius is the distance from the center to the farthest corner, which authors today approximate with:
- a hardcoded circle(141.42%) (only correct for square boxes), or - computing Math.hypot(width, height) in JS and injecting it via a custom property. The JS workaround is common enough that Chrome View Transitions documentation <https://developer.chrome.com/docs/web-platform/view-transitions/same-document> teaches it for the circle-reveal demo (see the Math.hypot snippet under “Animating with JavaScript”). That doc even notes: “The animation ends with the circle having a radius to the farthest corner. Although, hopefully this will be possible with CSS in future.” With it, the pattern becomes circle(farthest-corner at x y) no JS, no aspect-ratio assumptions, correct for any box. This is also partly an interop fix. The keywords are already part of the css-shapes-1 grammar <https://drafts.csswg.org/css-shapes-1/#basic-shape-functions> ( circle() takes <radial-size>, defined in css-images, which includes closest-corner and farthest-corner), and they already work in radial-gradient(), so authors reasonably expect them in circle()/ellipse(). WebKit shipped support in 2024 and exported the WPTs for it: WebKit/WebKit#31678 <https://github.com/WebKit/WebKit/pull/31678> Positions: - WebKit: support (implemented and shipped) - WebKit/standards-positions#719 <https://github.com/WebKit/standards-positions/issues/719> - Mozilla: shipped behind flag - mozilla/standards-positions#1450 <https://github.com/mozilla/standards-positions/issues/1450> Updated the feature entry as well. do you have any hints on how i can gather more developer-signal, or is there any documentation on how to get this? cheers, helmut Am Mo., 14. Sept. 2026 um 23:11 Uhr schrieb Alex Russell < [email protected]>: > I'm a little less worried about browser signals here than I am about > developer signals. Do we have confirmation that this solves an important > problem for web authors? > > Best, > > Alex > > On Wednesday, September 2, 2026 at 11:36:29 AM UTC-7 Mike Taylor wrote: > >> Yes, thanks. :) >> >> https://github.com/WebKit/standards-positions >> https://github.com/mozilla/standards-positions >> On 9/2/26 2:22 p.m., Chris Harrelson wrote: >> >> Hi Helmut, >> >> Just to clarify: Mike is asking for Mozilla and Safari standards >> positions issues, not additional developer signals. >> >> On Wed, Sep 2, 2026 at 11:20 AM Helmut Januschka <[email protected]> >> wrote: >> >>> trying to figure out to get signals >>> >>> Am Mi., 2. Sept. 2026 um 20:19 Uhr schrieb Helmut Januschka < >>> [email protected]>: >>> >>>> sadly, same as on my other feature entry, i forgot the checkmark, >>>> fixed! sorry >>>> >>>> [email protected] schrieb am Montag, 24. August 2026 um 19:23:24 >>>> UTC+2: >>>> >>>>> On 8/23/26 10:06 a.m., Helmut Januschka wrote: >>>>> >>>>> *Contact emails* >>>>> [email protected] >>>>> >>>>> *Specification* >>>>> https://drafts.csswg.org/css-shapes-1/#basic-shape-functions >>>>> >>>>> *Summary* >>>>> The circle() and ellipse() CSS basic-shape functions accept the >>>>> closest-corner and farthest-corner radius keywords, in addition to the >>>>> existing closest-side and farthest-side. These keywords resolve to the >>>>> Euclidean distance from the shape center to the nearest or farthest corner >>>>> of the reference box, matching the long-standing behavior of >>>>> radial-gradient(). They work in clip-path, shape-outside, and offset-path, >>>>> so the same shape syntax accepted by gradients now works for shapes. CL: >>>>> https://chromium-review.googlesource.com/c/chromium/src/+/7767079 >>>>> >>>>> *Blink component* >>>>> Blink>CSS >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> >>>>> >>>>> *Web Feature ID* >>>>> shapes <https://webstatus.dev/features/shapes> >>>>> >>>>> *Motivation* >>>>> The <radial-extent> keywords closest-corner and farthest-corner are >>>>> defined for radial gradients and have been interoperably supported there >>>>> for years. The circle() and ellipse() basic-shape syntax in CSS Shapes >>>>> Module Level 1 shares the <shape-radius> production with gradients, but >>>>> Blink (and Gecko) only accepted closest-side / farthest-side for the basic >>>>> shapes. That means authors who want a circle that exactly inscribes the >>>>> reference box's farthest corner have to hand-compute sqrt(w*w + h*h)/2 or >>>>> fall back to a radial-gradient() mask, even though the keyword exists in >>>>> the same value space. This change fills in the missing keywords so basic >>>>> shapes have the full <radial-extent> set: closest-corner: the distance >>>>> from >>>>> the center to the closest corner of the reference box. farthest-corner: >>>>> the >>>>> distance from the center to the farthest corner of the reference box. For >>>>> ellipse(), which accepts two independent <shape-radius> values in current >>>>> implementations, each axis resolves independently to the corner Euclidean >>>>> distance. A spec ambiguity exists about whether ellipse() should accept >>>>> one >>>>> <radial-extent> covering both axes (per the spec text) or two independent >>>>> ones (current implementation reality). This was discussed in >>>>> https://github.com/w3c/csswg-drafts/issues/13814 and the conclusion >>>>> from the thread was that the existing two-value interpretation is fine to >>>>> keep. >>>>> >>>>> *Initial public proposal* >>>>> *No information provided* >>>>> >>>>> *TAG review* >>>>> *No information provided* >>>>> >>>>> *TAG review status* >>>>> Not applicable >>>>> >>>>> *Goals for experimentation* >>>>> None >>>>> >>>>> *Risks* >>>>> >>>>> >>>>> *Interoperability and Compatibility* >>>>> *No information provided* >>>>> >>>>> *Gecko*: No signal >>>>> >>>>> *WebKit*: No signal >>>>> >>>>> Can we request signals? >>>>> >>>>> >>>>> *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 >>>>> >>>>> Why not? >>>>> >>>>> >>>>> *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* >>>>> BasicShapeCornerRadius >>>>> >>>>> *Rollout plan* >>>>> Will ship enabled for all users >>>>> >>>>> *Requires code in //chrome?* >>>>> False >>>>> >>>>> *Tracking bug* >>>>> https://crbug.com/361617757 >>>>> >>>>> *Estimated milestones* >>>>> Shipping on desktop 155 >>>>> Shipping on Android 155 >>>>> Shipping on WebView 155 >>>>> Shipping on iOS 155 >>>>> >>>>> *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/5100672946143232?gate=5910108950364160 >>>>> >>>>> 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/CAFmjHKSp4M_xW9Y4_1x56p_kLHBsY8_NdBUgYAqLjcKTUUsS2w%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKSp4M_xW9Y4_1x56p_kLHBsY8_NdBUgYAqLjcKTUUsS2w%40mail.gmail.com?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/CAFmjHKQp%3DoqVbRRX_iUxx3hn7_24XDW_vG5Sb1kJEvrQhUEWCg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKQp%3DoqVbRRX_iUxx3hn7_24XDW_vG5Sb1kJEvrQhUEWCg%40mail.gmail.com?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/CAOMQ%2Bw-XQD4u7_3N5i9z7MupFRq_jJVQ5WK5ABwJyr6t6o9_bg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-XQD4u7_3N5i9z7MupFRq_jJVQ5WK5ABwJyr6t6o9_bg%40mail.gmail.com?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/CAFmjHKRG_i3zh-%3DbKY5JOnu1kqz%2B2ahPqkLGH0X5-GwFX72N2A%40mail.gmail.com.
