[css-borders-4] corner-shape initial value ("round") is strange in some cases (e.g. bevel)

[jsnkuhn]

RESOLVED: Initial value of corner-shape is round

#10993 (comment)

Wouldn't the initial value for corner-shape have to be square/rect? to match most existing elements on the web? And that would mean "square/rect" would also need to be an option. So that we could do something like corner-shape: square angle square square;

(#6980 (comment))

[noamr]

corner-shape works together with the existing border-radius.
So if the above example had border-radius: 10, the corner-shape would default to round bevel round round.
The square shape makes the border-radius defunct, and that's why it seems like it should be the default, but round makes the most (or only) sense when thinking of corner-shape as a progressive enhancement to border-radius.

[jsnkuhn]

When I create an element on the web it's default corner shape is square. The heart of the problem here is the shoehorning of border-radius into the situation acting as a "corner-size" and "corner-shape" which forces rounded corner "fallbacks" whenever corner-shape is used even if that styling is inappropriate/unwanted like with notch, scoop, bevel, or sometimes even squircle.

An example to illustrate is this page for the upcoming pokemon game (https://www.pokemon.co.jp/ex/legends_z-a/ja/story/). The beveled corners on the h1 are there to mirror the header background image that includes it's own baked in bevels. A forced round fallback for the declared bevel would visually contrast with the rest of the page design. This will mean that the dev/designer will have to dance around a poor forced fallback.

I can't think of another situation like this in CSS when a non-default style is forced on developers when a certain property is used. It would be something like if a developer declared an unsupported p3 background color the browser just gives you red and pretends that is helpful Or if your background-image doesn't load in the browser were to just give you a linear-gradient(blue,orange).

A way around this problem is to create a corner-size property to go along with corner-shape and then allow devs to use border-radius as a fallback if they chose to.

[noamr]

A way around this problem is to create a corner-size property to go along with corner-shape and then allow devs to use border-radius as a fallback if they chose to.

What would be the default shape with a non-zero corner-size, and how would it interact with a border-radius?
Seems like those would be mutually exclusive properties that kind of do the same thing with different defaults, and I think we'll end up in a more confusing place than where we've started.

I agree that when the design is mostly straight, falling back to something rounded is not ideal visually. I think something like this is more readable than introducing an additional corner-sizing property:

@supports (corner-shape: bevel) {
  border-radius: 10px;
  corner-shape: bevel;
}

[jsnkuhn]

What would be the default shape with a non-zero corner-size, and how would it interact with a border-radius?

my immediate thought is a square default shape but maybe this is where you'd need a corner-shape of none as a default?

my thought is if corner-size or corner-shape are used border-radius just does nothing? It would only function as a fall back if those properties are not used.

I think something like this is more readable than introducing an additional corner-sizing property

i don't think that asking for the radius of a bevel, notch, or square is very readable

[noamr]

i don't think that asking for the radius of a bevel, notch, or square is very readable

Those are very specific values though, and animating between them + all the other values createa curved in-betweena with a radius.

That was the logic for going with general superellipse as the underlying value rather than special-casing bevel/notch.

If you think of bevel/notch as a superellipse with a 0/-infinity value, it doesn't only make them more consistent with the term "radius" but also makes those relative to the other values and thus animatable.

[jsnkuhn]

I'm aware that the implementation of this uses a superellipse and it's what got all of this off the ground and I appreciate that but I don't think that in practice any front-end dev/designer (really anyone other than the engineers that implement this) will think about it this way.

[noamr]

@jsnkuhn do you mind formulating the corner-size alternative into a more comprehensive proposal that can be discussed at the CSSWG? Right now I don't see it as a viable alternative to having corner-shape as an enhancement of border-radius (which means round is the default), but with enough details perhaps the point can be argued at a WG discussion.

[jsnkuhn]

As much as I'd like to be able to say "yes" to this I can not dedicate that amount of time to this without pay. Is there potentially a developer advocate at Chrome that can be brought in here to help?

[noamr]

Fair enough!

@SebastianZ @LeaVerou @fantasai @smfr @bramus @tabatkins @yisibl does anyone else resonate with the points here, of perhaps having a separate sizing attribute because some corner shapes are not a "radius"?

The fact that the combination of "bevel" and "radius" seems odd resonates with me, but I believe what we've achieved is still the best tradeoff.

[noamr]

@jsnkuhn btw corner-shape: square is a valid value. It's not the initial value because of the border-radius thing.