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/74a85d03-8ddd-4c4f-978d-3401d51b7e0bn%40chromium.org.
