[css-borders-4] Specify how borders are rendered for corner-shape

[noamr]

Follow-up on #10993

corner-shape cannot be naturally stroked in the same way as ordinary rounded corners or a stroke path, and some details need to be defined.

For example, how should stroking bevel/notch look like? Do the inner border collapse into each other, or stay confined within the corner?

[noamr]

I created a codepen that renders corner-shape using @fserb's formula to approximate superellipses (more on that later), and shows how I think the borders should work:
https://codepen.io/noamr/pen/WbNQEvP?editors=1111

Basically, to achieve the effect where the thickness of the border is equal to the relevant border-width, while painting within the corner bounds, the outer radius as to be lower than the inner radius for curvatures more concave than round.

This becomes very apparent with notch:

And also with bevel

Or scoop:

In the prototype, the outer radius is reduced in a number that's a function of the corresponding border and the curvature.
The offset would be an intercept for a parallel line to the tangent of the curve at a (border-width) distance.

(It still looks a bit off at around scoop though, so we're not done with the formula)

[jsnkuhn]

I have a hand full of examples of partial bordered corner-shape like examples that might be worth taking a look at here:

#9072

and a couple of others from the giant use case thread:

#6980 (comment)
#6980 (comment)

[noamr]

I have a hand full of examples of partial bordered corner-shape like examples that might be worth taking a look at here:

#9072

and a couple of others from the giant use case thread:

#6980 (comment) #6980 (comment)

Thanks, I wonder how these use case translate to the specifics of border rendering?
Some of these seem to be semi-rounded notches which we've been discussing on a different thread.

[jsnkuhn]

In this example I notice that the thicker right border's width is maintained through the entirety of the top-right angled corner. The width of the drawn border does not transition from the border-top-width to the border-right-width like in the codepen. Or is there a way to accomplish this that I'm not seeing?

[noamr]

In this example I notice that the thicker right border's width is maintained through the entirety of the top-right angled corner. The width of the drawn border does not transition from the border-top-width to the border-right-width like in the codepen. Or is there a way to accomplish this that I'm not seeing?

There is no current semantic for defining where the corner gets the border-width from, so it interpolates between the two sides... A corner like in the picture would only be available with border-shape ATM.

[smfr]

I've drawn up some diagrams of how I think bevel and scoop should be rendered. Note that with uneven border widths, you can't think of rendering the border as stroking a path; it has to be inner and outer paths computed separately.

Bevel

The goal is to have the bevel section maintain the border width. Naively joining the points you'd use for round result in a thinner diagonal.

Proposed algorithm for computing the inner border edge:

1. Take the points where the outer border bevel corners are
2. From each, compute a line perpendicular to the the bevel, with a length given by the border width on that side (w1, w2)
3. Compute a line that intersects the inner ends of the lines from step 2
4. Compute where that line intersects the two inner border sides

Scoop

The goal here again is to maintain the width of the scoop section, and also to have the inner scoop edge prescribe an ellipse around the outer box corner (this looks better than perpendicular joins at the inner edges).

Proposed algorithm for computing the inner border edge:

1. Compute an ellipse whose center is the outer corner, whose x radius is the (border-radius width + border width on the horizontal side) and whose y radius is (border-radius height + border width on the vertical side)
2. Compute the intersections of the relevant ellipse quadrant with the inner border edges

[noamr]

The formula in the codepen is sort of what you wrote for bevel. It's equivalent to reducing the outer radius by border-width*sqrt(2)-1, for the width relevant to the side of the corner the path is at. A similar formula is applied to scoop and all the other superellipses so that's probably why it doesn't look great there.

[jsnkuhn]

In this example I notice that the thicker right border's width is maintained through the entirety of the top-right angled corner. The width of the drawn border does not transition from the border-top-width to the border-right-width like in the codepen. Or is there a way to accomplish this that I'm not seeing?

There is no current semantic for defining where the corner gets the border-width from, so it interpolates between the two sides... A corner like in the picture would only be available with border-shape ATM.

In practice what I'd be more likely to do than draw out the 2 more complicated paths (likely with a generator) for border-shape here is use a consistent 1px border then extend the right/left sides with drop-shadows (assuming drop-shadow works the way I expect).

corner-size/border-radius: 0 14px / 0 20px;
corner-shape: square bevel;
/* (or just `bevel` i guess because the 0 corner size will make the corner square anyway?) */
border-color: solid 1px #a1c3ca;
filter: drop-shadow(2px 0 #a1c3ca) drop-shadow(-2px 0 #a1c3ca);

[noamr]

A focused discussion for the WG here is whether concave corner borders (scoop/notch) can be allowed to overlap each other. The alternative is to shrink the outer radius and create some kind of join.

I believe the latter is a reasonable constraints for corners, however some use cases will not be possible (a sharp "star" using scoops where the borders overlap). Note that this would be possible with border-shape.

This prototype attempts to solve the join problem to appear consistent with the existing rounded/square shapes.

[tabatkins]

Hm, I notice in your prototype that the point on the border's outer edge that looks like it starts the corner stays constant while the border is convex, but moves slightly closer to the corner as it becomes concave. I presume this is what Simon was referring to.

@smfr, in your diagrams, could you indicate exactly what parts are intended to correspond to the specified radiuses? I presume it's the length of the outer dashed sides?

[noamr]

Hm, I notice in your prototype that the point on the border's outer edge that looks like it starts the corner stays constant while the border is convex, but moves slightly closer to the corner as it becomes concave. I presume this is what Simon was referring to.

Yes, this is intentional. It creates an effect where scoop is a mirror image of round in the opposite corner, while staying within the bounds,

[smfr]

Amended diagrams (text slightly garbled by OmniGraffle export):

[noamr]

@smfr I looked at the bevel formula and generalized it to any superellipse, by using the approximate tangent.
It basically works like a bevel, where the line goes to the control point of the arc equivalent to the superellipse (have the same value at t=0.5). I think it works the same for scoop.

It looks something like this:

  // a and b are the coordinates for the contol point of the approximate arc
  a = 0.5 ^ (1/k);
  b = 1 - a;
  slope = a / b;
  magnitude = hypot(a, b);
  norm_a = a / magnitude;
  norm_b = b / magnitude;

  // This compute the intercept of a line parallel to the tangent, at distance (1)
  outer_offset = norm_b + slope * (norm_a - 1);

  // outer_offset can now be multiplied by the stroke width to compute the join size (actual outer offset)

[noamr]

Hm, I notice in your prototype that the point on the border's outer edge that looks like it starts the corner stays constant while the border is convex, but moves slightly closer to the corner as it becomes concave. I presume this is what Simon was referring to.

Update: I changed the algorithm in the prototype to modify the inner radius instead, but constrain the radius so that it doesn't overlap (effectively shrinking the outer radius when close to 50%).

[noamr]

After many iterations together with @smfr and @fserb, I think we have a good model:

• Shaped borders do not create new constraint on the radius. Instead, they are clipped by the outer shape, and can overlap with each other when concave. This allows creating shapes like a scooped star:

• The border should have its specified interpolated thickness through entire length when possible. Same for shadows. This requires a formula similar to this one, but one that's applicable for arbitrary curvature. As a general rule, it should feel like two superellipse quadrants, with the same center, same curvature, and a different radius. It's basically what @smfr describes in [css-borders-4] Specify how borders are rendered for corner-shape #11610 (comment), but applied to all superellipses.
• Dashed/dotted borders etc should be rendered side-after-side, which might create some overlaps. This would be consistent with the convex versions in case of animations.
• Color joins should work similar to how they work for ordinary rounded corners - they should either cross diagonally between the border and padding edges, or try to slice the corner at its middle.

Would love to get a resolution on this soon!

Feel free to play with the different options on https://noamr.github.io/squircle-testbed/corner-shape.html
Note that it doesn't render color joins correctly, but everything else should be fine.

@tabatkins @fantasai @LeaVerou @yisibl

[tabatkins]

That definitely feels pretty good to me when I play around with it a little, and your description matches how I think they should work. While we still need to define the diagonal-corner overlap avoidance rules (which your demo mostly avoids, by limiting the radiuses to half the half the side size), I like the shape of this chunk of the rules.

(By the way, there's a rendering bug if some of the corners are zero radius.)

[yisibl]

@noamr Sorry for the late reply. This looks very nice, I see that there are two Mode options at the bottom, does the actual implementation of Blink use the bezier curve approximation as well?

[noamr]

@noamr Sorry for the late reply. This looks very nice, I see that there are two Mode options at the bottom, does the actual implementation of Blink use the bezier curve approximation as well?

Currently in canary, blink uses the bezier curve approximation and the web platform tests use point-by-point superellipse.

[smfr]

Here are my test pages for corner inner/outer edge rendering

https://noamr.github.io/squircle-testbed/corner-visualizer/shape-renderer.html

and with some explanatory control points:
https://noamr.github.io/squircle-testbed/corner-visualizer/corner-geometry.html

(inner edge intersection is not handled yet).

I think the main question here is what level of detail the spec should go into. "UAs should attempt to preserve border thickness for various corner shapes", or something more detailed?

[noamr]

Here are my test pages for corner inner/outer edge rendering

https://noamr.github.io/squircle-testbed/corner-visualizer/shape-renderer.html

and with some explanatory control points: https://noamr.github.io/squircle-testbed/corner-visualizer/corner-geometry.html

(inner edge intersection is not handled yet).

I think the main question here is what level of detail the spec should go into. "UAs should attempt to preserve border thickness for various corner shapes", or something more detailed?

I think we should say that, and also that the borders don't affect the constraint of the outer shape, only go inwards - which means there could be overlaps in some cases.

[css-meeting-bot]

The CSS Working Group just discussed [css-borders-4] Specify how borders are rendered for `corner-shape` , and agreed to the following:

• RESOLVED: Radii are resolved for the outer shape just as for existing border-radius rounded-rect shapes
• RESOLVED: Inner curve gets clipped as soon as it intersects the inner edge of any adjacent side/corner
• RESOLVED: smfr and noam to spec the math that makes the inner curve look good

The full IRC log of that discussion

<TabAtkins> noamr: this has been a lot of work
<TabAtkins> noamr: how detailed does this need to be in the spec?
<TabAtkins> noamr: there's an intricate algorithm to make the corner appear consistent
<TabAtkins> noamr: like if you have two adjacent scoops, we want them to cut into each other
<TabAtkins> noamr: top-right and bottom-right both "scoop 50%"
<TabAtkins> noamr: the outer border follows the shape math. the inner borders can overlap
<TabAtkins> noamr: don't have a clear idea of how to do this in the spec, but maybe we wnat to say that the border thicknesses need to be consistent at the start and end
<TabAtkins> noamr: border overlap does not constrain the radius
<TabAtkins> noamr: and are clipped by the outer radius
<TabAtkins> noamr: so you can create shapes that fold into themselves
<astearns> ack fantasai
<TabAtkins> fantasai: I think the behavior you're takling about is that we determine the radiuses per the formula, we shape the outer border edge, then we shape the inner border edge to match by offsetting the endpoints of the corner shape (where it connects to the straight part of the border) by insetting those normal to the curve, and using that to inperolate the inner line, then clipping the inner curve
<TabAtkins> fantasai: so you don't get overlapping
<TabAtkins> fantasai: i do think we need to spec it
<TabAtkins> noamr: also, for very high or low curvatures, outside of 1/-1, we adjust the inner curvature
<TabAtkins> noamr: in this example, the inner and outer have a differnet superellipse value to make the thickness appear consistent
<TabAtkins> noamr: so question is to what extent is needed to specify
<TabAtkins> fantasai: need to specify as far as getting the same math, so impls can match.
<fantasai> fantasai: Can allow for approximation, but we need interop here
<fantasai> TabAtkins: Should be testable in WPT with some amount of pixel fuzziness
<fantasai> TabAtkins: Is your inner ellipse calculation similar to the interpolation, where you get the diagonal width correct and then figure out the superellipse param?
<TabAtkins> noamr: not exactly, it creates a vector... it's not just moving the lines, the superellipse needs the same center too
<TabAtkins> noamr: it's all similar math
<TabAtkins> noamr: i create a line perpendicular to the hull (two straight lines snug to the superellipse) and make something perpendicular to that
<TabAtkins> noamr: i can't use the half corner here
<TabAtkins> noamr: i think the important bit here is if we're okay with the behavior here, that the border width doesn't affect the outer-radius shape
<TabAtkins> noamr: so it stays the same as for normal rounded rects
<TabAtkins> fantasai: i think that makes sense
<TabAtkins> +1
<fantasai> TabAtkins: In particular, getting the star shape is a desired behavior
<fantasai> PROPOSED: Radii are resolved for the outer shape just as for rounded-rect
<fantasai> RESOLVED: Radii are resolved for the outer shape just as for existing border-radius rounded-rect shapes
<fantasai> fantasai: inner radius gets clipped as soon as it hits any side or other corner
<fantasai> PROPOSED: Inner radius gets clipped as soon as it intersects the inner edge of any adjacent side/corner
<smfr> q+
<fantasai> s/radius/radius curve/
<TabAtkins> (exact details matter when the borders are partially-transparent, fwiw)
<fantasai> PROPOSED: Inner curve gets clipped as soon as it intersects the inner edge of any adjacent side/corner
<astearns> ack smfr
<TabAtkins> smfr: i think we do radius cosntraints for existing round rects, we shirnk so they dont' join on the inside?
<TabAtkins> fantasai: no, it's the outer curve we care about
<TabAtkins> smfr: just want to make sure we have consistent behavior
<TabAtkins> fantasai: right, we just now resolved to be consistent with the outer radius.
<TabAtkins> fantasai: you don't really have the problem the inner radius for curves
<TabAtkins> fantasai: the current formula onlya pplies to the outer radius
<TabAtkins> fantasai: and as a consequence the inner radius doesn't intersect
<TabAtkins> fantasai: but it's the outer radius that's controlled by border-radius
<fantasai> RESOLVED: Inner curve gets clipped as soon as it intersects the inner edge of any adjacent side/corner
<fantasai> PROPOSED: smfr and noam to spec the math that makes the inner curve look good
<fantasai> RESOLVED: smfr and noam to spec the math that makes the inner curve look good