- From: Mattia Astorino via GitHub <sysbot+gh@w3.org>
- Date: Mon, 09 Oct 2023 20:59:24 +0000
- To: public-css-archive@w3.org
> agree, `match-nearest-parent` is weak compared to specifying which container to compute against 👍🏻
>
>
>
> could combine @justinfagnani and @DarkWiiPlayer) suggestions?
>
>
>
> ```css
>
> .card {
>
> container: card / normal;
>
> border-radius: 24px;
>
> }
>
>
>
> .card picture {
>
> border-radius: concentric(card) concentric(card) 0 0;
>
> }
>
> ```
>
>
>
> if authors don't specify the container, it's the nearest container by default:
>
>
>
> ```css
>
> .card picture:only-child {
>
> border-radius: concentric();
>
> }
>
> ```
Does it work if there are many wrapping elements between .Card and the picture? I mean there are common situations where you don't have control over where the element with `concentric()` is placed. And the nearest parent may not have any `border-radius` set.
Is that bad if the keyword/function behaves like the position absolute (depending on the first position relative ancestor), in this case depending on to the first ancestor with `border-radius`?
--
GitHub Notification of comment by equinusocio
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7707#issuecomment-1753856238 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 9 October 2023 20:59:25 UTC