On Mon, Jun 16, 2025 at 9:22 PM Alex Russell <slightly...@chromium.org> wrote:
> Excited to see this! > > Has the TAG weighed in on the proliferation of related but different > shorthand syntaxes in this area? We have `superellipse()` here and > `cubic-bezier()` in easing. Should we provide both in each system? If not, > why not? > There was no such discussion at TAG or at CSSWG. See https://github.com/w3ctag/design-reviews/issues/1090 Interesting question though, will have a crack at answering it! First of all, there is another feature in development (expect an I2P soon) that would allow general purpose bezier curves and any other shapes in borders, called border-shape: https://drafts.csswg.org/css-borders-4/#border-shape A superellipse and a cubic bezier are different mathematical formulas, with different purposes. It's possible to approximate a superellipse corner with two or more cubic beziers (that's what the blink implementation does under the hood). Superellipses are very compelling for corners because they can be divided to 8 symmetrical parts, which means each corner can render two of those curves with their meeting point in the middle. Also the superellipse spectrum goes between fully concave (notch) and fully convex (square), with several visually interesting points along the way, like a straight diagonal line at k=0, (bevel), round at k=1, and squircle at k=2. So it's convenient to reason about its values and to animate between them. A key thing about superellipse-based corner-shapes, unlike the general-purpose bezier-based border-shape, is that because of this symmetry, the corner can curve like a superellipse but still remain "in the corner", retaining symmetry in the middle, while a cubic-bezier can go anywhere... This allows us to do things with corner-shapes such as supporting the existing border-styles (e.g. dotted) and having different border widths and colors per edge. This would be much more challenging (not to say impossible) with a general purpose border-shape with cubic beziers - border-shape as currently proposed will not support varied border widths, colors and styles, while corner-shape certainly does. So this is an explanation of why a superellipse corner-shape can do some things that a general purpose border-shape can't, and vice versa, so they both have room :) As for using superellipse() in timing functions etc where cubic-bezier() is available, it's certainly possible given enough demand. However, I suspect that the visual subtlety of the superellipse would be lost in a non-visual field like time. I am not sure if it would add any value there, but if someone asks for it, it can be revisited. Hope my answer here helps clarify! -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYaaWhEjPEnvuHP4Pj6x3wnj3oW48VV4vuj_oJZ0cJ2waQ%40mail.gmail.com.
