[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.

[jsnkuhn]

I can try and clarify what I'm asking a bit:

Important point is that there would be no cross over between border-radius and the corner- properties. border-radius would continue doing what it does unless corner-shape and corner-size are declared as something other than none i guess? In that case the corner- properties would take over and border-radius would do nothing. (this leaves open the opportunity for the future for border-radius to round the joints of the corner-shapes. (side note: I was told that this would be too complicated to do - too many control points - but that has been said about a lot of things in CSS in the past that have ultimately happened so it seems best to leave this open as a possibility.)

border-radius could then be used as a fallback for the corner- pair if one or the other of the corner- properties is not none. This would also allow the use of different border-radius values for the fallback. I don't think this would be a common need but seems like it might be useful with larger squircle shapes:

corner-shape: squircle;
corner-size: 50px;
border-radius: 99999px;

[LeaVerou]

I've always thought that rounding is an odd and not very useful fallback for most corner shapes. In many cases, rectangular corners would be a much better fallback. But most importantly, keeping them separate allows for them to be combined, e.g. using border-radius to add rounding to the polygonal shape that angle or square corners can create. (see #9843 for use cases). Perhaps the two could be combined with a separate property to control what border-radius rounds.

[noamr]

I see the #9843 as more related to stroke, like "stroking the border with round joins" rather than something that's connected with border-radius.

I think that with squircles and similar round-ish shapes (which is one of the major use cases for this) falling back to rounded corners makes a lot more sense than falling back to having zero radius.

I think we can do the following:

• border-radius effectively a shorthand (of sorts, given that it's already a shorthand for the different corners) for corner-size: $radius; corner-shape: round;
• We separately think of rounding the strokes, which is a separate thing than border-radius (for example, it doesn't affect the inner clipping etc)

I am not sure if this is very necessary but definitely possible if it makes things more readable for designers.
In either case, this lets us add corner-size later as a readability enhancement.

[jsnkuhn]

another example here to show that the border-radius fallback won't even always be what devs want when falling back from squircle.

The squircle design I'm trying to make is the blue element in the middle. Its a squircle of 70px.

The red element on left is the forced border-radius: 70px; fallback. It looks nothing like what I want. The corners are crowding the links way too much.

The yellow element on the right is a close enough approximation of what I want with default round border-radius but the value has to be 35px (half of the squircle value) to get there.

So even in this case I'd have to @supports my way around the default fallback.

https://codepen.io/jsnkuhn/pen/MYwYLXv?editors=1100

[noamr]

OK, to clarify how I think this would work if we accept this direction:

• we add a corner-shape: auto value, which becomes the default, and a corner-size property.
• If corner-size is not none, it takes precedence and corner-shape: auto resolves to square.
• Otherwise, auto resolves to round and border-radius is used as a fallback.

This allows using border-radius as an optional fallback for corner-size.

Note that this is backwards compatible with what's being built right now, however it means that until something like corner-size is shipped people would have to use the existing @supports mechanism to opt out of the border-radius fallback.

[noamr]

Another option, perhaps, better, is to have a corners shorthand:

   <<corner-shape-and-size>> = none | [ <<corner-shape-value>> && <<length-percentage [0,&infin;]>>{1,2} ]
   <<corners>>: <<shape-and-size>> [ / <<corner-shape-and-size>> ]{0, 3}

Where the author has to specify both a shape and a size (neither are optional), but can declare 1..4 corners. e.g.:

corners: bevel 10px / round 20% 30px / none / squircle 3px;

This way, authors can be sure that the radius they provide is attached to a particular shape and doesn't individually fall back to border-radius.

Note that this does not introduce new longhands - it would resolve to border-radius and corner-shape as they are now.

[tabatkins]

I don't think I agree with the core argument of this thread. If a value isn't supported, there is no fallback that is guaranteed to be correct. Defaulting to "round" is just as likely to be reasonable as defaulting to "square", without context, and I think in practice it's much more likely to be correct.

Looking at the examples given in this thread:

• I think the weather example would look just fine falling back to "round".
• The pokemon example would be just as visually jarring if it fell back to "square" corners, as the placement of the menu items is dependent on the bevel angle and it would create a funky "staircase" effect, so neither fallback is actually very good for it.

There wasn't an example of this given in the thread yet, but squircle corners would definitely be best falling back to "round". The concave values are a harder sell, just because there's no close example, but if I had to choose between "round" and "square" to render a "scoop" with, I think I'd still choose a "round" as the most reasonable default, simply because it cuts out something from the corners and breaks up the strict rectilinear lines, which is usually the core of the effect you're reaching for.

If your particular use-case disagrees with this, and you think square would be a better fallback in older browsers, we already have a solution for that - @supports. I don't think we should add a secondary way of specifying border radiuses; seeing both a 'border-radius' and 'corner-size' on an element, and having to tell that 'border-radius' is ignored unless one of the 'corner-*' properties for that corner is "none", is confusing. We try our best to avoid those sort of override designs unless we have a very good reason.

That said, I definitely wouldn't object to a 'corners' shorthand setting both 'border-radius' and 'corner-shape', which would happen to function as a "soft" fallback to square corners in legacy UAs (since they'd ignore the shorthand and not end up setting 'border-radius' either). corners: squircle 2em is definitely nicer than border-radius: 2em; corner-shape: squircle;.

[jsnkuhn]

There wasn't an example of this given in the thread yet, but squircle corners would definitely be best falling back to "round".

There is an example of squircles above: #11623 (comment)

As stated there while round can be a good fallback shape for squircle the radius/size value might need to be different from squircle to round.

I guess the other thing to keep in mind is that hopefully any issues with fallback for unsupported browsers won't be around that long. The only issue that would remain long term is questions like "why is CSS asking for the radius of a notch or an angle".

Very much agree that there should be a corners shorthand.

[noamr]

Proposing #11623 (comment) as a resolution for this issue.
A shorthand that requires particular shapes would have a long term nice ergonomic benefit, while also addressing the particular browser compat issue in a lightweight manner without introducing two sources of truth.

[fantasai]

I'd be fine with adopting either or both of #11623 (comment) (corners shorthand) and #11623 (comment) (border-radius shorthands corner-size + corner-shape) but strong -1 to #11623 (comment) or any other proposal that creates multiple "sources of truth" for the corner-shape radii.

[LeaVerou]

+1 to corners from me too. In addition to solving the problem at hand, it may well be the way to finally get rid of the border-radius name without the downsides of introducing an alias.

[yisibl]

+1 to corners from me too.

[noamr]

I think there is general consensus here.
Proposing an async resolution:

A corners shorthand:

   <<corner-shape-and-size>> = none | [ <<corner-shape-value>> && <<length-percentage [0,&infin;]>>{1,2} ]
   <<corners>>: <<shape-and-size>> [ / <<corner-shape-and-size>> ]{0, 3}

e.g.

corners: bevel 10px / round 20% 30px / none / squircle 3px;

[tabatkins]

What corner shape is implied by "none"? Obviously it's a radius of 0px. Is it "round"?

[noamr]

What corner shape is implied by "none"? Obviously it's a radius of 0px. Is it "round"?

Yes, '0px round'