Re: [csswg-drafts] [css-borders-4] New `border-radius` value for perfectly matching nested radii (#7707)

Just a thought, as the complexity seems to be building as @LeaVerou pointed out— could this be a good use case for [declarative functions](https://github.com/w3c/csswg-drafts/issues/7490), if all these non-% radii use cases are essentially variable interpolation?

Here is a nested border-radius example using different values for both the `border-radius` at each corner, as well as `padding` per each side: [CodePen](https://codepen.io/brandonmcconnell/pen/oNJmKEK/420fc494dd19ef71a5d89b9e58e8eef5).

<details><summary><b>(expand/collapse source)</b></summary><br />

```html
<parent>
  <child></child>
</parent>
```
```css
parent {
  --br-tl: 30px;
  --br-tr: 48px;
  --br-br: 82px;
  --br-bl: 130px;
  --p-t: 20px;
  --p-b: 10px;
  --p-r: 26px;
  --p-l: 44px;
  border-radius: var(--br-tl) var(--br-tr) var(--br-br) var(--br-bl);
  padding: var(--p-t) var(--p-r) var(--p-b) var(--p-l);
}

child {
  border-radius: calc(var(--br-tl) - var(--p-t)) calc(var(--br-tr) - var(--p-r))
    calc(var(--br-br) - var(--p-b)) calc(var(--br-bl) - var(--p-l));
}
```

</details>

Using declarative functions with a new `self()` function to get computed values for other properties on the same element (think `this` in an element method in JS), the complex CSS could all be abstracted away like this:

<details><summary><b>(expand/collapse source)</b></summary><br />

```css
@custom-function --get-nested-radius {
  result: calc(self(border-top-left-radius) - self(padding-top))  calc(self(border-top-right-radius) - self(padding-right)) calc(self(border-bottom-right-radius) - self(padding-bottom)) calc(self(border-bottom-left-radius) - self(padding-left));
}

parent {
  border-radius: 30px 48px 82px 130px;
  padding: 20px 10px 26px 44px;
  --nested-radius: --get-nested-radius();
}

child {
  border-radius: var(--nested-radius);
}
```

</details>

I'm sure I'm missing some level of that calculation where the corner radius needs to account for the padding of both sides it touches and take a weighted average of the two, but this is essentially the idea.

I agree that having something like this built into the browser could be handy, but if there's any part of this that could potentially change based on use case, would it be better to leave that calculation up to the end user/dev?

Btw if there's a more accurate parent-directed formula to build the nested `border-radius` value than what I came up above, could someone please let me know what that would be? Thanks in advance 🙏🏼

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


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

Received on Wednesday, 11 October 2023 00:05:01 UTC