Re: [csswg-drafts] [css-syntax][css-nesting] Design of `@nest` rule (#10234)

@mirisuzanne Love the creative thinking. Especially since making this rule useful seems like the only path forward with such strong objections from both sides.

Since `@group {}` with no name needs to apply its content to the rule it's specified on would that apply its declarations when there is no name and store them for later reference if there is a name? That seems a little strange to me, and also clashes with #9992 and mixins. 

---

Thinking about it some more, I actually think the IACVT idea might be the lowest hanging fruit and meshes well with the use case of representing declarations on the same level (i.e. it would not have to become a separate rule): we've always said IACVT is necessary because we've thrown away the fallback declarations by then, welllll… `@group` allows us to preserve them! This also means it does not have to become a grouping rule. I think it's the idea that is closest to how `@nest` was envisioned.

It could become a convention to have groups as levels of cutting edge-ness:

```js
.foo {
 /* Fallbacks for old browsers */
 color: white;

 @group --baseline-2024 {
  color: color-mix(in oklch, var(--color) 30%, oklch(50% 0.01 none / none));
 }

 @group --cutting-edge {
  color: oklch(from var(--color) 30% clamp(0.01, c * .8, .1) h / alpha);
 }
}
```

The `<dashed-ident>` can be dropped, people can always use comments for that.

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


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

Received on Friday, 26 April 2024 16:37:45 UTC