[css-borders] Add shorthand for `border-shape` / `corner-shape` / `border-radius`

[nt1m]

The shorthand could be like this:

border-shape: <border-shape-path> | [ <corner-shape> || <border-radius> ] (syntax tbd, including to control the 4 corners )

You'd be able to specify things like this:

border-shape: bevel 30px

border-shape: squircle 30px

cc @noamr @SebastianZ @LeaVerou @fantasai @bert-github

[noamr]

Isn't this identical to inset(0 squircle 50%) etc? perhaps it makes more sense as a basic-shape shorthand than something specific to border-shape?

Having a shorthand raises the question of how a border-shape: round 20% is prioritized alongside border-radius: 30% etc. Usually a longhand has higher priority than a shorthand, but border-shape has higher priority than border-radius. So perhaps allowing inset or rect to not provide coordinates would be cleaner? like border-shape: inset(squircle) or bordrer-shape: inset(bevel 30%)

[nt1m]

Sorry, I wasn't clear in my proposal. border-shape would become the shorthand, and then the existing border-shape would become border-shape-path or something, which would be a longhand of border-shape.

Given corner-shape and border-radius go hand in hand, we should be able to set them together from one shorthand.

[noamr]

Thinking about this a bit, I wonder if we can make border-shape a bit more descriptive.

• A one-shape contour is actually a stroke
• A two-shape contour is actually a fill between those shapes
• The other ones are a box

So something like a border-contour shorthand (or we can repurpose border-shape and add other longhands):

/* Two paths. The fill color is determined by clipping the regular border colors or here */
border-contour: fill between polygon(...outer..) and shape(...inner...) with black;

/* Single path. The stroke color is determined by the `stroke` property or here  */
border-contour: stroke shape(...) with 1px black roundjoin dashed(10px 5px);

/* A box with corners+edges, defined from top-left clockwise, repeating in the same manner as border/border-radius.  */
border-contour: box with 10px squircle / 20px groove green /  none / 5px solid black;

[LeaVerou]

One thing to note is that "contour", while more accurate, is a word that is less friendly to non native speakers compared to "shape".

More substantively:

• I like the core idea, I think it makes a lot of sense. There are also a lot of use cases around variable strokes along a path, I wonder if it can cover them (not necessarily now).
• It seems the two paths case is basically a Porter-Duff operator and should ideally be handled by a new shape function that takes <shape> args? compound()?
• I'm finding the second and third examples pretty hard to read TBH (but perhaps the complexity is inherent in the use cases)

[noamr]

One thing to note is that "contour", while more accurate, is a word that is less friendly to non native speakers compared to "shape".

More substantively:

• I like the core idea, I think it makes a lot of sense. There are also a lot of use cases around variable strokes along a path, I wonder if it can cover them (not necessarily now).
• It seems the two paths case is basically a Porter-Duff operator and should ideally be handled by a new shape function that takes <shape> args? compound()?

It's not porter-duff... there's no alpha channel involved.
It's more like an even-odd fill.
border-shape is already meant to support this, I've proposed to make that syntax clearer here

border-shape: box | stroke <<basic-shape>> | between <<basic-shape>> and <<basic-shape>

• I'm finding the second and third examples pretty hard to read TBH (but perhaps the complexity is inherent in the use cases)

Perhaps with that syntax in the above link we don't need an additional shorthand that tries to cover everything about borders? It gets a bit DSL-ish, and perhaps individual properties are more readable.

[yisibl]

perhaps individual properties are more readable.

I hold my hands up, the grammar on it really isn't easy to read.