[css-borders-4] Rendering of outset shadow spread with concave 50% corner-shapes

[noamr]

The current spec for adjusting border-radius assumes that spread behaves like an extended border.
However, when dealing with concave corners that meet each other (50%), this feels a bit strange.

e.g:

    .target {
        position: absolute;
        left: 50px;
        top: 50px;
        width: 200px;
        height: 300px;
        box-sizing: border-box;
        corner-shape: superellipse(-0.5) notch scoop bevel;
        border-radius: 50%;
        background: green;
        border: 20px solid purple;
        box-shadow: 0 0 2px 20px orange;
    }

The shadow spread outer path is basically rendered here like a stroke bevel join (or something similar).

This is more pronounced when all the corners are bevel (rhombus):

Basically the spread extends the edges of the rect, making a rhombus into an octagon of sorts.

This is probably in line with the philosophy of shadow-spread being a stroke of sorts, but I wanted to verify that with everyone.

[noamr]

/cc @smfr @Loirooriol @fantasai @svgeesus @tabatkins @yisibl @jsnkuhn

[smfr]

I think this is OK, and preferable to dealign with pointy miters that could extend out far.

[Loirooriol]

I agree it looks a bit weird. But extending it further would mean that the shadow will no longer be within the border rect expanded outwards by the spread distance. In particular, for small angles, the bounding shadow rect could be huge. Are we fine with that?

[yisibl]

This appears equivalent to the current outline rendering. From the user's perspective, the box-shadow should definitely maintain a diamond shape; otherwise, it would look significantly different from a real physical projection.

You can also compare the rendering effect of filter: drop-shadow().

Additionally, is it possible to algorithmically fill in the missing triangular portion?

[noamr]

I agree it looks a bit weird. But extending it further would mean that the shadow will no longer be within the border rect expanded outwards by the spread distance. In particular, for small angles, the shadow rect could be huge. Are we fine with that?

It's a tradeoff... I'm fine either way with a slight inclination to the current interpretation of the spec (bevel join)

[noamr]

This appears equivalent to the current outline rendering. From the user's perspective, the box-shadow should definitely maintain a diamond shape; otherwise, it would look significantly different from a real physical projection.

box-shadow spread already looks different from any physical projection of a shadow. It's more like a glorified half-stroke with offset/blur.

You can also compare the rendering effect of drop-shadow().

That's where you can use actual shadow projection rather than using box-shadow spread.

Additionally, is it possible to algorithmically fill in the missing triangular portion?

That would be a miter join instead of a bevel join. But in some cases that triangle could be somewhere between huge and infinite and makes it possible for the shadow to go beyond the projected rectangular shadow, which was not possible so far.

[SebastianZ]

I'd somehow expect a round join.

Sebastian

[jsnkuhn]

In the all bevel rhombus example personally I would not be expecting the beveled line join by default.

Just had a look through the use case example thread (#6980) and I did not find any example of a bevel mitered join on an outer "border".

If you render the beveled miter by default and people don't want it there's nothing they can really do to work around it. If someone does want the bevel joint and it's not there they could use for example clip-path: inset(-16px); to cut off the bits they don't want.

Maybe this needs it's own CSS a property?

SVG has a stroke-linejoin property to control this. The default is miter not bevel
https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/stroke-linejoin#usage_context

Canvas has linejoint. The default is also miter not bevel
https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/lineJoin#value

[astearns]

An alternate default that avoids too-pointy extensions could re-use the shape-margin algorithm

https://drafts.csswg.org/css-shapes-1/#shape-margin-property

[noamr]

I've prototyped doing this with round/miter join stroke of the border path:

I think the "round join" option is actually pretty satisfactory.
It would need to apply the corner-adjusted radius as well.

[yisibl]

I tested this in Figma and Sketch. By default, their shadows use miter joins.

• In Figma, when the default is set to miter join, it switches to bevel join when a certain threshold is exceeded.
  
• In Sketch, there appears to be no threshold; shadows simply become very long.
  
• When adding rounded corners, they all become round joins.
  

So, I think we could add a keyword similar to round in polygon() here. Or perhaps a new property: box-shadow-round: <length>

When its value is 0, it resembles a miter join; when greater than 0, it becomes a round join.

Maintaining consistency with design software facilitates design fidelity. In Figma or Sketch, corresponding CSS code can be generated directly.

Sketch

Sketch-App.mp4

Figma

figma.mp4

[noamr]

Yea that would be a miter with a miter limit (these concepts are pretty well established). But I would prefer to have some sort of default (probably round) and only add more customizability for this later if there's demand.

[yisibl]

But I would prefer to have some sort of default (probably round) and only add more customizability for this later if there's demand.

Yes, it can default to round, meaning box-shadow-round: 1px.

Of course, this can be discussed by opening a new issue.

[smfr]

I really don't want box-shadow to gain a whole set of shaping features. I think it's better to not encourage use of shadows with outsets, and instead enhance borders (and maybe outlines) for these kinds of effects.