There's an additional inconsistency that also applies to the circle() function: only -side keywords are allowed, not -corner keywords.

Was there any reason for not allowing circle() and ellipse() shape functions to use closest-corner and farthest-corner to define radii?

@AmeliaBR closest-corner and farthest-corner did not seem necessary for shape-outside and clip-path, as using those for radii often creates a shape that extends outside the margin box. I'm not against allowing them for consistency's sake, but I don't know that they would get much use.

@astearns The reference box for sizing a clip-path or shape-outside doesn't need to be the margin-box. A circle sized to the content box's corners could still fit within the margin box. And the shape functions may be adopted for other uses.

But regardless of the strength of use cases, I agree with Tab's original point that consistency is preferred.

I should have addressed this a few years ago. Sorry for the delay.

Adding the *-corner keywords should be fine.

My guess is it's still possible to change the ellipse() syntax to exactly match radial gradients. If we do that, there will be some breakage. It would be limited to instances of ellipse() where two keywords are used (which is likely very small), and the breakage would be limited to having someone's shape-outside or clip-path no longer apply (both have okay fallbacks).

BUT I think we could change ellipse() to allow either what's currently specified OR something matching a current radial gradient:

<extent-keyword> | [ <extent-keyword> | <length-percentage> ]{2}?

Then there would be no breakage, no one would get a surprise trying to copy a radial gradient ellipse into an ellipse(), we would get the two-keyword case (which is useful for creating ellipses that are the largest that can fit in a reference box), and we could decide whether to extend the radial gradient syntax to match (fully containing the ellipse is less useful there, but still could be good)

Hmm. If we allowed two keywords and both *-side and *-corner, then we'd have to define what it means when both keywords were *-corner. It's not immediately obvious to me what the resulting ellipse should be in those cases.

If we allowed two keywords and both *-side and *-corner, then we'd have to define what it means when both keywords were *-corner. It's not immediately obvious to me what the resulting ellipse should be in those cases.

Oh, that's a good point. And may have been the reason the radial-gradient syntax only allows one keyword.

So the natural superset of the two syntaxes is one or two "side" keywords or lengths, or one "corner" keyword. Which is rather more confusing.

I can assure you that's not why I wrote radial-gradient the way I did; I just happened to think of the ellipse/circle keywords as an automagical way to write the two sizes.

Given that closest-corner is defined to create an ellipse with the same aspect-ratio as closest-side that passes through the closest corner point we could do something similar for the two-keyword form:

X-corner Y-corner creates an ellipse with the same aspect-ratio as X-side Y-side that passes through both corners

@astearns

closest-corner and farthest-corner did not seem necessary for shape-outside and clip-path, as using those for radii often creates a shape that extends outside the margin box. I'm not against allowing them for consistency's sake, but I don't know that they would get much use.

I have a use-case!

@keyframes circular-reveal {
  from { clip-path: circle(0 at center); }
  to { clip-path: circle(farthest-corner at center); }
}

Right now this is only possible with JS.

Agenda+ at @jakearchibald 's request

The CSS Working Group just discussed ellipse() grammar gratuitously inconsistent with radial-gradient(), and agreed to the following:

• RESOLVED: update the basic shape functions and update radial-gradient

Yay!

Follow-up on the recent change.

Is it intentional to not allow mixing an extent keyword and a length/percentage?

That is, <radial-extent>{1,2} | <length-percentage [0,∞]>{1,2} vs. [<radial-extent> | <length-percentage [0,∞]>]{1,2}.

Two-component values remain invalid when specifying circle

What about a single size component value specified with ellipse?

From reading the normative value definition and the prose in CSS Images 3, a single <percentage> is invalid but a single <length> is valid. Browsers follow the value definition in the non-normative note, which disallows a single component value, regardless of its type.

While it would be confusing to allow eg. circle 100% 120%, maybe you can relax this restriction for ellipse? The second value would default to the first one.

Note that it would mean that one of circle, ellipse, or both size component values, should be explicit in the serialization, when a single size component value was specified, because circle 100% does not mean the same as ellipse 100% 100%.

If you prefer to require two size component values with ellipse, maybe this restriction can be hard-coded this way:

<radial-gradient-syntax> = <radial-shape>? [ at <position> ]? , <color-stop-list>
<radial-shape> = [ circle || <radial-size> ] | [ ellipse || <radial-size>{2} ]
<radial-size> = <radial-extent> | <length-percentage [0,∞]>

Can you open a new issue on this followup, @cdoublev?