Re: [csswg-drafts] [css-borders-4] Interaction of single-path `border-shape` with non-uniform `border-width` (#11662)

> This would mean that a roundrect would have its arc corner segments take their width from _one of_ the sides they're joining, but exactly which side depends on the arc's aspect-ratio, right? In your linked example, the curvy segment is thick and green (the 'left' styles) because the straight-line path between the segment endpoints is slightly more upright (it shifts 170 horiz and 180 vert), and thus "points at" the left side? (Yeah, confirmed that if it lands on -10 0, so 190 horizontal shift, it takes from the bottom.)

Yea that's right.
An option I've mentioned, specifically for beziers, is to split them at the extremas (local max-x/max-y points). That way each sub-curve would have a more natural direction. Not sure if this is the right tradeoff for simplicity though or if it would look the best.


> 
> What do you do if it's a tie? (I presume it'll just take from one or the other arbitrarily.)

I thought, as an (added complexity) extension of this, that the borders would have corners in addition to the sides, defined by `border-radius`. If a segment falls in the middle, it would break in half kind of like how colors/widths break for border-radius.

Again, not sure if the complexity is worth it but it could be very creative and also I believe it would produce nice results for things like octagons with non-uniform color/width.

> Hm tho, this could potentially work as the default. For cases where you're just, say, making a border with slanted lines for affect, this lets you have the "obvious" border style mapping. Can be a little weird in complex cases, but that's why we want to have the ability to specify the styles manually, too.

Yea exactly, also the two-shape variant is always available.

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


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

Received on Tuesday, 11 February 2025 21:14:43 UTC