andruud

@mirisuzanne Yeah, true. We already have this problem when the `@scope` is a nested group rule, though: ``` div { @scope (#foo) { color: green; /* Specificity=? */ } }...

> This would be 0,0,1 - a bit less surprising to me. No, keep in mind that the `` selector [acts as the parent rule](https://drafts.csswg.org/css-nesting-1/#nesting-at-scope) for `&`here. So per spec...

@mirisuzanne But the innermost rules would get 0,0,0 if we use `:where(:scope){}`, not 0,0,1. The innermost rules do not "see" the outer `div` rule. The thing that maintains a connection...

``` my-input { border-radius: 0px; @if-var(--pill = on) { border-radius: 999px; } } #my-input { --pill: off; } ``` @LeaVerou Just to make sure I understand the proposal, for ``...

(... interpreting that upvote as a "yes"): Having selector matching (`@if-var` is not very different from a nested `:if-var`) depend on computed-value-time things adds far too much complexity, even if...

There's overlap here with the ideas in https://github.com/w3c/csswg-drafts/issues/1594. > The problem is that UAs throw the other declarations away when they see a new one in the same scope. Ideally,...

@cdoublev Thanks, that's just an oversight. Will fix.

Closest I've seen is "custom env", https://github.com/w3c/csswg-drafts/issues/2627#issuecomment-386932374. There are also a few proposals for registering a bunch of custom properties (and their initial values) in a less verbose way. >...

> `` Will `` not do here?

> Having an unbounded set of ``, ``? , etc productions doesn't sound very safe in that regard Yeah, I agree with that. > And, personally, I think it [``]...