Re: [csswg-drafts] [css-borders] Interaction between `border-shape` and other border properties (#14149)

> https://drafts.csswg.org/css-borders/#border-shape
> 
> Currently, interaction with `border-width` and `border-color` is basically: 
> - Figure out the [relevant side](https://drafts.csswg.org/css-borders-4/#relevant-side-for-border-shape)
> - Use the `border-width` and `border-color` from that for the stroke
> - Throw away all other values but still occupy the same space as they would if this were not using `border-shape`
> - `border-style` isn't even part of the equation. Effectively, any value other than `solid` or `none` has no effect. There's no way to use a dashed or dotted stroke, even though that's perfectly well defined in SVG and makes perfect sense conceptually.

Note that border-style rendering is not specified regardless of border-shape. Rendering dotted or dashed borders according to border-style would be spec compliant.

> 
> This is …not great. 😕 From the author's point of view, many of these are interactions that _should_ work, though not all are equally valuable:
> - `border-width` is the worst one as it affects the box model. If the relevant side is smaller than the max width, surrounding content will overlap the border. If it's larger, there will be pointless empty space. Plus, many of the use cases for two shapes are actually one shape with `border-width` actually working.

Yea that's why we suggested to be able to override this with a stroke-like property. 

> - Dropping side colors is suboptimal, but I don't think it comes up much in practice. Nobody wants these hard angular transitions anyway.

I think what we came up with was the optimal solution. It was discussed multiple times.

> - Not all `border-style`s are equal. I think it's fine to ignore `inset`, `outset`, `groove`, `ridge` since they’re effectively legacy. But `dashed`, `dotted`, `double` make perfect sense.
> 

See above. UAs can render these and it would be spec compliant.

> Additionally, interactions with other planned features either in the same spec or resolved to be added to it are underspecified or not specified at all, such as:
> - [listified `border-color` and `border-width`](https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3813591962)
> - [Partial borders](https://drafts.csswg.org/css-borders-4/#partial-borders)

Yea we should define how these work with border-shape. Those were specified later and haven't shipped anywhere. Let's discuss each of these in isolation?

> 
> I know that the general problem of variable stroke width is considered hard, but do we need to solve the general problem? What if we introduce constraints about the type of shape that can be used? E.g. no self-intersection, max curvature bound, no cusps etc. We could even start strict and relax them over time with no API changes.
> 
> Alternatively (and probably more realistically), can we drop the relevant side rule and treat it as an error (at ??? time) if the border properties are not compatible? Then we can define reasonable interactions in the future without compat getting in the way.

I am not a big fan of error conditions. If this comes up as a problem in practice we can find a solution.


To sum up:
A. border-style rendering is not specified, but that's regardless of border-shape
B. the relevant side solution feels not great and might interfere with something in the future but it's unclear what
C. interactions with newer unshipped features is unspecified 

I am suggesting that 
A is a tangential issue about border-style in general;
B needs a bit more substance to be reasoned about;
C can be addressed in the context of these new features and is likely solvable.



-- 
GitHub Notification of comment by noamr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/14149#issuecomment-4936108349 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 10 July 2026 14:00:30 UTC