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.
