[css-borders-4] corner-shape naming

[jsnkuhn]

While doing some theoretical poking around at recreating some of these Shapes of CSS (https://css-tricks.com/the-shapes-of-css/) with corner-shape I found myself wanting to call it corner-style instead. Presumably to line up with the existing border-style property.

Also was wondering about the opportunity to "fix" the "border-radius should have been corner-radius." from the Incomplete List of Mistakes in the Design of CSS https://wiki.csswg.org/ideas/mistakes

The pairing of corner-radius and corner-style just reads better to me that corner-shape and border-radius the later 2 don't really feel like they go together. Maybe border-radius and corner-radius could be aliased by browsers?

https://drafts.csswg.org/css-backgrounds-4/#corners-shorthand

[LeaVerou]

I suppose corner-style would allow for more customization options in the future as well. It is also consistent with list-style and border-style. Thoughts, @fantasai?

(though the primary problem with that property isn't naming, it’s lack of implementor interest…)

[jsnkuhn]

I do remember there being some initial push back. But I thought the issue was it just wasn't ready for implementation yet. I know it's existed in spec form for a long time but the only place I see it is on css-backgrounds-4 with the big "not ready for implementation" banner: https://drafts.csswg.org/css-backgrounds-4/

[jsnkuhn]

So in an effort to see if implementer interest exists now I've opened bugs in both Chrome and Firefox:

Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1242936&q=corner%20shape&can=2
Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1726232

[bradkemper]

I have thoughts.

To me, corner-shape makes more sense; it is more evocative and precise for what it is expected to do. For something that effects the corner in some non-shape way, there could be another corner-* property, and it could be added to the corners shorthand.

Also, putting aside that we didn't really name border-style very well (I mean come on, all of CSS is style, that's what the first "C" stands for), when I hear/read corner-style, I think it would mean border-style for the corners. Which is actually a very good idea, IMO. If we had that, then border-limit, etc. wouldn't be needed, and it would be more intuitive.

For instance, if you wanted solid corners and no lines between the corner shapes, you would do this:

corner-radius: 30px;
border-style: none;
corner-style: solid

Maybe we should have corner-color too.

[jsnkuhn]

if we're looking for something more accurate than style the terminology that comes to mind is what comes from svg and canvas I guess i'd say things like corner-stroke, corner-stroke-width, corner-path, and corner-stroke-dasharray.

[jsnkuhn]

stumbled on this completely by accident: in the definition for border-image-slice there is a reference to corners and edges.

This property specifies inward offsets from the top, right, bottom, and left edges of the image, dividing it into nine regions: four corners, four edges and a middle.

so we have border that refers to the stroke all the way around the element, corners referring to just the... corners and edges is used to refer to everything that's not a corner i guess.

https://drafts.csswg.org/css-backgrounds-3/#border-image-slice

So would that mean we'd need matching edge- properties to go with corner- properties. All of which would over write the existing umbrella border- properties?

[jsnkuhn]

Thinking in the context of border-image-slice it seems that instead of border-radius or corner-radius we might want to consider using corner-size instead? Doesn't make sense to me to think about the radius of a circle that would fit into the full corner size square if your looking to create a square notch. A border-radius of 1px there would create a 2x2 square which i don't think peeps would expect. You'd really need to think more like border-diameter which would essentially just be the corner width and height anyway?

[jsnkuhn]

Thinking that maybe corner-size should be more similar to background-size than border-radius?

So, corner-size: 20px 30px, 0, 0, 0; instead of corner-size: 20px 0 0 0 / 30px 0 0 0;

• having width and height per corner right next to one another is more readable than having widths to the left of the slash and height to the right of the slash
• reduces need for repetition
• single value should equal both width and height (as listed on https://wiki.csswg.org/ideas/mistakes with background-size mistake)

[jsnkuhn]

Random thoughts mostly on naming:

• Reusing border-radius forces a round corner fallback and honestly I don't know if i'd ever really want that. the default rectangle corner shape seems like a better fallback for angle and notch to me. Maybe it's useful for scoop?

• for what it's worth I've personally settled on --corner-shape and --corner-size as property names in the PaintAPI polyfill I've been working on.

• corners should probably be corner because CSS properties are singular.

• more and more been wondering if corner-shape should just be part of CSS-Shapes as a corner() function. Note that inset() already has an optional param for rounding ( clip-path: inset(10px round 8px);) that probably would need to be built on with the other corner-shape options. Feels at the moment that the rounding is hiding inside inset() and should just be broken out as its own thing.

This way coner() could be reused as part of something like element-shape, clip-path, shape-inside/outside, and to make a background/mask/border-image etc.?

[LeaVerou]

Random thoughts mostly on naming:

• Reusing border-radius forces a round corner fallback and honestly I don't know if i'd ever really want that. the default rectangle corner shape seems like a better fallback for angle and notch to me. Maybe it's useful for scoop?

Agreed.

• for what it's worth I've personally settled on --corner-shape and --corner-size as property names in the PaintAPI polyfill I've been working on.

That would be nice indeed, though then we'd need to define how border-radius and corner-radius interact when both are set.

• corners should probably be corner because CSS properties are singular.

There is precedent of this pattern (singular longhands, plural shorthand) with multicol: column-count and columns

• more and more been wondering if corner-shape should just be part of CSS-Shapes as a corner() function. Note that inset() already has an optional param for rounding ( clip-path: inset(10px round 8px);) that probably would need to be built on with the other corner-shape options. Feels at the moment that the rounding is hiding inside inset() and should just be broken out as its own thing.

This way corner() could be reused as part of something like element-shape, clip-path, shape-inside/outside, and to make a background/mask/border-image etc.?

I think that actually makes sense. Right now, many use cases for corner shape are essentially hacks that are trying to use it to set element shape. We do have #6997 for element-shape though do note this is significantly more complex and thus could take a long time to happen (if it ever does). In general a lot of the complexity with these things has to do with borders, especially when they are all different (different widths, styles, colors).