Re: [csswg-drafts] [css-shapes-2] corner-shape support for superellipsis (#10993)

I quite like this! The fact that it directly handles straight lines (bevel), round corners, squircles, *and* square corners (and the *inversions* of all of them; scoop and notch) is great; it also gives us an unexpected new ability to *animate between these shapes*, which kinda rules.

I don't think it's a problem that the function takes numerical value with "magic numbers". That's just a result of making *anything* parametrized. The fact that all the "meaningful" behaviors (those common enough to be granted names) are the integer values 0, ±1, and ±2, and ±∞ means, imo, that the argument is meaningful enough.

I definitely agree with log-rescaling the parameter. It makes the function substantially easier to use and understand, with amazing symmetry (positive and negative values are the exact same shape, just convex or concave). It also makes "large enough to look square" a much more achievable value, and thus much friendlier to animation; going from `se(10)` to `se(1)` to animate a square corner becoming round looks fairly reasonable even with a linear ease (while doing the same with the original parameter would require `se(1024)` to `se(2)`, which spends 99% of the animation progress being approximately square). And, due to the symmetry around zero, animating inset corners and outset corners works exactly the same, which is a very good thing. I did the same rescaling with aspect-ratio animation, which has the exact same "shape" (naive range is 0-inf, centered at 1), and it was the right move.

Quick note about animation - I suspect we want to have keywords compute to themselves, but convert to an equivalent `se()` during interpolation. Just something to keep in mind when speccing it.

And yeah, as you mention (and is also mentioned by Simon and me in <https://github.com/w3c/csswg-drafts/issues/8591#issuecomment-2299899979>), we'll need to define how concave corners (negative `se()` arguments) shrink their corresponding radiuses to avoid diagonal intersection. We can't take the easy route of just preventing the "corner rectangles" from overlapping, as that's already allowed by border-radius today (see `border-radius: 100% 0 100% 0;`). I'm assuming that, since superellipses have an easy radial interpretation, this isn't that complicated to detect and mitigate.

-------

Unfortunately I do not have a better name suggestion. However, maybe we can simply avoid the issue entirely, and just represent it as a naked `<number>` in the grammar? This *does* look like a sufficiently general/useful parametrization of the corner shape that it can meaningfully usurp the entire definition.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10993#issuecomment-2389642249 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 2 October 2024 20:30:33 UTC