Re: [csswg-drafts] [css-borders-4] Specify how borders are rendered for `corner-shape` (#11610)

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> noamr: this has been a lot of work<br>
&lt;TabAtkins> noamr: how detailed does this need to be in the spec?<br>
&lt;TabAtkins> noamr: there's an intricate algorithm to make the corner appear consistent<br>
&lt;TabAtkins> noamr: like if you have two adjacent scoops, we want them to cut into each other<br>
&lt;TabAtkins> noamr: top-right and bottom-right both "scoop 50%"<br>
&lt;TabAtkins> noamr: the outer border follows the shape math. the inner borders can overlap<br>
&lt;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<br>
&lt;TabAtkins> noamr: border overlap does not constrain the radius<br>
&lt;TabAtkins> noamr: and are clipped by the outer radius<br>
&lt;TabAtkins> noamr: so you can create shapes that fold into themselves<br>
&lt;astearns> ack fantasai<br>
&lt;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<br>
&lt;TabAtkins> fantasai: so you don't get overlapping<br>
&lt;TabAtkins> fantasai: i do think we need to spec it<br>
&lt;TabAtkins> noamr: also, for very high or low curvatures, outside of 1/-1, we adjust the inner curvature<br>
&lt;TabAtkins> noamr: in this example, the inner and outer have a differnet superellipse value to make the thickness appear consistent<br>
&lt;TabAtkins> noamr: so question is to what extent is needed to specify<br>
&lt;TabAtkins> fantasai: need to specify as far as getting the same math, so impls can match.<br>
&lt;fantasai> fantasai: Can allow for approximation, but we need interop here<br>
&lt;fantasai> TabAtkins: Should be testable in WPT with some amount of pixel fuzziness<br>
&lt;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?<br>
&lt;TabAtkins> noamr: not exactly, it creates a vector... it's not just moving the lines, the superellipse needs the same center too<br>
&lt;TabAtkins> noamr: it's all similar math<br>
&lt;TabAtkins> noamr: i create a line perpendicular to the hull (two straight lines snug to the superellipse) and make something perpendicular to that<br>
&lt;TabAtkins> noamr: i can't use the half corner here<br>
&lt;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<br>
&lt;TabAtkins> noamr: so it stays the same as for normal rounded rects<br>
&lt;TabAtkins> fantasai: i think that makes sense<br>
&lt;TabAtkins> +1<br>
&lt;fantasai> TabAtkins: In particular, getting the star shape is a desired behavior<br>
&lt;fantasai> PROPOSED: Radii are resolved for the outer shape just as for rounded-rect<br>
&lt;fantasai> RESOLVED: Radii are resolved for the outer shape just as for existing border-radius rounded-rect shapes<br>
&lt;fantasai> fantasai: inner radius gets clipped as soon as it hits any side or other corner<br>
&lt;fantasai> PROPOSED: Inner radius gets clipped as soon as it intersects the inner edge of any adjacent side/corner<br>
&lt;smfr> q+<br>
&lt;fantasai> s/radius/radius curve/<br>
&lt;TabAtkins> (exact details matter when the borders are partially-transparent, fwiw)<br>
&lt;fantasai> PROPOSED: Inner curve gets clipped as soon as it intersects the inner edge of any adjacent side/corner<br>
&lt;astearns> ack smfr<br>
&lt;TabAtkins> smfr: i think we do radius cosntraints for existing round rects, we shirnk so they dont' join on the inside?<br>
&lt;TabAtkins> fantasai: no, it's the outer curve we care about<br>
&lt;TabAtkins> smfr: just want to make sure we have consistent behavior<br>
&lt;TabAtkins> fantasai: right, we just now resolved to be consistent with the outer radius.<br>
&lt;TabAtkins> fantasai: you don't really have the problem the inner radius for curves<br>
&lt;TabAtkins> fantasai: the current formula onlya pplies to the outer radius<br>
&lt;TabAtkins> fantasai: and as a consequence the inner radius doesn't intersect<br>
&lt;TabAtkins> fantasai: but it's the outer radius that's controlled by border-radius<br>
&lt;fantasai> RESOLVED: Inner curve gets clipped as soon as it intersects the inner edge of any adjacent side/corner<br>
&lt;fantasai> PROPOSED: smfr and noam to spec the math that makes the inner curve look good<br>
&lt;fantasai> RESOLVED: smfr and noam to spec the math that makes the inner curve look good<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11610#issuecomment-2769797194 using your GitHub account


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

Received on Tuesday, 1 April 2025 15:40:07 UTC