[css-borders-4] Clarify the non-elliptical nature of `corner-shape: scoop`

[satgo1546]

The scoop value for corner-shape is not an exact opposite of round — in fact, far from it.

red: true circular arc
blue: superellipse(-1) or scoop as defined per spec

The spec addresses this in a collapsed section "How does a superellipse work?":

[…] a K of -1 gives a nearly elliptical "scoop" that’s roughly the opposite of a K of 1, […]

Note the words 'roughly' and 'nearly'.

However, the definition of scoop seems to imply that it is elliptical.

The corner shape is a concave quarter-ellipse. Equivalent to superellipse(-1).

Figure 1 is also misleading in that the curve for K = -1 is drawn as a circluar arc symmetric to the case of K = 1.

I believe it should be clarified that the scoop shape is not a quarter-ellipse, and the effects of positive and negative values of K are asymmetric.

Incidentally, Chromium has implemented superellipse(K) with negative K values as the perfect opposite of those with positive K values, which is not compliant. I've created an issue there, too.

[tabatkins]

The spec actually does define that negative K values are interpreted as the opposite of the positive value, rather than actually being the X^(1/N) power.

[satgo1546]

The spec actually does define that negative K values are interpreted as the opposite of the positive value

Could you please give a pointer to the relevant section? I must've been missing something if that's the case...

[tabatkins]

Yup, it's in https://drafts.csswg.org/css-borders-4/#normalized-superellipse-half-corner:

1. Let k be 0.5 ^ abs(s).
2. Let convexHalfCorner be 0.5^k.
3. If s is less than 0, return 1 - convexHalfCorner.

[satgo1546]

Oh, I see. I've skipped the algorithms before. It makes sense now.

I suppose it is better to at least mention such a discrepancy between a mathematical superellipse and a CSS superellipse() in prose, then? In the current form of the spec, a reader can not see the fact unless they work through the details of the algorithms.