[css-borders-4] Interaction of single-path `border-shape` with non-uniform `border-width`

[noamr]

border-shape allows a single-path variant, which is an arbitrary shaped border.
It's not resolved exactly where this path gets its stroke width from.

Option 1: uniform border-width

Take the top border width and ignore the rest, perhaps allowing a more granular way to provide a stroke later on

Option 2: Cutoff points with interpolations

See comment by @fserb in #6997_

The cutoff points can be based on the point in the path, or based on a diagonal between the border box and the padding box.

One proposal for border-width interaction.

Break it down in two steps.

Step 1. Assume a width(t) function that returns the width of the border parametrized over its length (t=0 begin of the path,, t=1 end of a continuous path). For each path, the width(t) function can be applied to create an outer shape by moving the path outside in the direction of the normal of the path.

Step 2. How to build width(t). One option is to allow the user to specify a function or 1d gradient directly for each continuous path. But let's ignore that for now. Can we build a reasonable function given border-width? I think so. We can define "control points" (similar to what we have today): 0 - 0.25 - 0.5 - 0.75 - 1.0. Each interval gets one width. And then we specify a transition range: so, something like: width(t) = border-top-width [0.05, 0.2], lerp(top, right) [0.2, 0.3], right [0.3, 0.45] ... etc. We can decide how much control/flexibility to give. This function would be applied to every continuous path on the shape.

Would something like this work?

Option 3: Use point-by-point tangents:

See this comment , not sure if I chose the right name for it. Quoting the direction:

Conceptually, the general idea was: for each point along the path, you find the tangent, and draw a vector perpendicular to the tangent with a length calculated as follows:

• If the angle is a multiple of 90deg, then it directly maps to one of the four border widths.
• Otherwise, you compute its proximity to the two adjacent angles that are multiples of 90deg and do a weighed average of the two border widths.

I don’t have access to our sketches as I write this, but it seemed to us that this would produce a very nice result for many common cases, and a not-terrible result for edge cases.

Ideally, the single shape syntax should allow specifying either the border edge (and draw the border on the inside of it) or the padding edge (and draw the border on the outside of it). We'd still need to decide how to do line joins and miter limits.

@svgeesus @fserb we'd love your feedback!

Option 4: interpolate each path segment based on nearest border to its end points

The idea is inspired by option 3, but is perhaps simpler as it works with whole segments and not point by point:

For each target point in the path:

• find the straight line that's perpendicular to the segment between that point and the point before it (for the first "move to", use the point after it)
• find the side that intersects with the perpendicular, and has an even number of other segments in between. There should be one
• use that border width
• emit two points that are perpendicular to the segment at the target point, each half width away
• For the control points, interpolate the width based on the position of the line perpendicular to the control point that intersects with the segment's straight line

• The options are a bit hard to read as quotes from comments, will try to edit them before we discuss this.

[noamr]

I've experimented with trying to create some options using canvas, and created this partially working demo:
https://noamr.github.io/border-shape-testbed/index.html

I think this model works pretty well for NONZERO shapes.
It's inspired by the model suggested before by @LeaVerou and @tabatkins, but adjusted to not having to rely on a point-after-point computation of stroke width and interpolating a bezier's stroke, which can be too computationally expensive.

1. Divide the path into closed subpaths
2. divide each closed subpath into segments
3. If counter-clockwise, reverse
4. For each segment:
   4.1. Choose the stroke width and color by which border is to the left of the vector created by the segment.
   e.g. a segment that points to the right would receive the top border.
   4.2. Expand each subpath by the chosen stroke width, as if it was a line, creating an inner and outer subpath
5. Trim/expand the outer and inner subpath start/end points to intersect with its respective adjoining segments
6. for each segment, create a path between the join points and the stroke boundary
7. Fill that path with the chosen color

@fserb @tabatkins @nt1m @fantasai @smfr @LeaVerou WDYT?

[smfr]

I think step 4 is "for each segment"?

I'd like to see some more complex paths, and sketches for how the segment joins would work.

[noamr]

I think step 4 is "for each segment"?

Thanks, corrected

I'd like to see some more complex paths, and sketches for how the segment joins would work.

Yup, agreed that would be the next step. I wanted to see if something like this is desirable before doing some of the heavy lifting around bezier joins.

[noamr]

@smfr I improved it to work well for bezier curves (see demo).
It works as follows:

1. Divide the path into closed subpaths
2. divide each closed subpath into segments
3. If counter-clockwise, reverse
4. For each segment:
   4.1. Choose the stroke width and color by which border is to the left of the vector created by the segment.
   e.g. a segment that points to the right would receive the top border.
   4.2. create the inner and outer outline paths for the segment. For a bezier, this could become several beziers
   4.3 Extend/trim the first/last point in each outline linearly to intersect with the adjoining first/last segment.
   For beziers, the segment is the tangent at the start/end (which is the straight line to the control point).
   4.4 fill the quad between the inner and outer outlines

We can achieve something like a color per inner curve if we split each bezier curve at the extrema at the beginning of 4, but I didn

[tabatkins]

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.)

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

---

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.

[noamr]

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.

[noamr]

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.)

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

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.

I played around with this and updated the demo to have an opt in for splitting curves at the inflection/extrema point(s).
I think the inflection one looks pretty promising and perhaps what one would expect from auto-splitting paths into a box border?

[tabatkins]

Hm, I'm not sure what exactly it's doing right now; given https://noamr.github.io/border-shape-testbed/index.html?path=m+40+30+h+100+c+20+0+20+0+20+20+v+100+c+0+20+0+20+-20+20+h+-100+c+-20+0+-20+0+-20+-20+v+-100+c+0+-20+0+-20+20+-20+z&wtop=4&ctop=%23e51f1f&rtop=4&cright=%23e5e817&btop=4&cbottom=%23350ff0&ltop=5&cleft=%2364e864&split=extrema the corners are still totally colored one way or another. (and it seems to change their shape a bit; this naive quadratic curve shouldn't look that round, and doesn't if you select "no split")

[noamr]

Hm, I'm not sure what exactly it's doing right now; given https://noamr.github.io/border-shape-testbed/index.html?path=m+40+30+h+100+c+20+0+20+0+20+20+v+100+c+0+20+0+20+-20+20+h+-100+c+-20+0+-20+0+-20+-20+v+-100+c+0+-20+0+-20+20+-20+z&wtop=4&ctop=%23e51f1f&rtop=4&cright=%23e5e817&btop=4&cbottom=%23350ff0&ltop=5&cleft=%2364e864&split=extrema the corners are still totally colored one way or another. (and it seems to change their shape a bit; this naive quadratic curve shouldn't look that round, and doesn't if you select "no split")

It doesn't fix the "tie" thing, but rather helps with beziers with multiple curves that point in different directions.

[smfr]

I'm not convinced that the results we're getting here are something that authors are actually going to want.