[css-borders-4] Resolve on range for `superellipse` parameters

[noamr]

Follow up on #10993

The initial draft for corner-shape and superellipse uses the following parameters:

• 0 is notch
• 0.5 is scoop
• 1 is bevel
• 2 is circle
• 4 is squircle
• 1 is straight

We can also use the log2 version of this:
notch -> -inf
scoop -> -1
bevel -> 0
round -> 1
squircle -> 2
straight -> inf

This would have an effect on the formula in #11608 as well.

[smfr]

inf values concern me because they aren't good endpoints for interpolation.

[smfr]

Actually, that makes me wonder if we need more detail on how the superellipse is computed, given a corner size (in pixels). It would be weird for a corner to appear sharp on a small box, but still slightly rounded on a large box because of how the math works out. We need math that is size-independent.

[noamr]

inf values concern me because they aren't good endpoints for interpolation.

This is addressed in the draft

[noamr]

Actually, that makes me wonder if we need more detail on how the superellipse is computed, given a corner size (in pixels). It would be weird for a corner to appear sharp on a small box, but still slightly rounded on a large box because of how the math works out. We need math that is size-independent.

You mean when we describe it as bezier curves? For the cartesian equation this shouldn't matter.

[tabatkins]

I strongly prefer the log2-scaled version of the superellipse parameter, so the symmetric inny and outy shapes use the same parameters, just negated; in general, it makes the "stuff poking out more than angle" and "stuff poking in more than angle" have the same value range and same value meaning, which is a lot easier to understand and use imo.

It also happens to make the most significant values even simpler - 0, 1, 2, inf.

Actually, that makes me wonder if we need more detail on how the superellipse is computed, given a corner size (in pixels). It would be weird for a corner to appear sharp on a small box, but still slightly rounded on a large box because of how the math works out. We need math that is size-independent.

You get a (mathematically) sharp corner at infinity and -infinity (or infinity and 0, in the current spec). And that's stable regardless of box size. Any value short of those endpoints will produce a curve with some extremely high curvature, so at a sufficiently large border-radius it will indeed appear curved rather than sharp.

[noamr]

I strongly prefer the log2-scaled version of the superellipse parameter, so the symmetric inny and outy shapes use the same parameters, just negated; in general, it makes the "stuff poking out more than angle" and "stuff poking in more than angle" have the same value range and same value meaning, which is a lot easier to understand and use imo.

Thanks! I tend to agree.

[noamr]

@smfr with my proposed formula for interpolation applied on these values it would look like this:

Name	superellipse() value	0..1 value for interpolation
notch	-Infinity	0
scoop	-1	0.25
bevel	0	0.5
round	1	0.7
squircle	2	0.84
straight	Infinity	1

The formula is intersecting the diagonal with the superellipse function, which resolves to this (given n as the arg):

// -Infinity => 0, Infinity -> 1, everything else given `n` as the `superellipse()` arg:
0.5^(1 / (2^n))

• there could be a way to simplify this formula further, my logarithmic math is rusty

[noamr]

An advantage for using the current spec'ed version (without log2) is that it's the commonly used exponent value for superellipse. So if designers say "this is a superellipse with k=5" you don't need to remember that in CSS this would be log2(5).