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
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.