gosh, sorry, shortly after LGTM3, CSSWG discussed the open ellipse() grammar question, but did not reach a resolution: https://github.com/w3c/csswg-drafts/issues/10812#issuecomment-5701278743
The question is specifically whether ellipse() should continue accepting two independent *-corner radii, as WebKit currently ships and the WPTs expect, or use a singular *-corner value that determines both radii. circle() is unaffected. My read is that the likely path is additive, retain the shipped two-value behavior and define the singular form. However, a singular-only resolution could require changing the accepted syntax or resulting geometry. Given the existing WebKit behavior, are you comfortable with me proceeding with the M156 flag flip and following up after CSSWG resolves this, or should I wait? the flag-flip CL: https://chromium-review.googlesource.com/c/chromium/src/+/8419499 cheers helmut Am Mi., 16. Sept. 2026 um 17:13 Uhr schrieb Rick Byers <[email protected] >: > LGTM3 > > On Tue, Sep 15, 2026 at 3:11 AM Yoav Weiss (@Shopify) < > [email protected]> wrote: > >> LGTM2 >> >> On Tue, Sep 15, 2026 at 3:18 AM Mike Taylor <[email protected]> >> wrote: >> >>> On 9/14/26 5:57 p.m., Helmut Januschka wrote: >>> >>> 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> >>> >>> Thanks - LGTM1 >>> >>> >>> >>> 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? >>> >>> Since this is a "catch up" feature, signals aren't a blocking concern >>> (for me personally, anyways). In general though, you could find blog posts >>> of developers asking for a feature (or describing their excitement about >>> it...), issues filed by developers, or comments in existing issues giving >>> support, etc. Sometimes these can surface in CSSWG discussions, or even TAG >>> issues. >>> >>> 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/f68dc11f-78a5-4b7f-a0f3-cc397934aa2c%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f68dc11f-78a5-4b7f-a0f3-cc397934aa2c%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/CAOmohS%2B2u4AdJRMbLmnTe9m5Ja%2B9vkSLYQy0KZLL2VQ059Tsbg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2B2u4AdJRMbLmnTe9m5Ja%2B9vkSLYQy0KZLL2VQ059Tsbg%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/CAFmjHKRVVAx4GDHO_ztFT6-SOP%3DaOynrhZhx6evHjwBmjYBB6g%40mail.gmail.com.
