-
Notifications
You must be signed in to change notification settings - Fork 658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-nesting] Allow custom property within nested at-rule conditions #8753
Comments
I don't follow your reasoning, I don't see why nesting should imply any change. Anyways, in #8088 we already resolved to allow |
Thanks for the heads up, somehow I missed that one in my searches. |
For |
I'm not sure I understand the distinction. You say that for However, you must define the container element using the very same selector
So you can also override
How does Also I don't think it's actually a problem that the variable If you want to treat |
It's not a matter of being able to change The difference is that |
I think I see what you're saying. To confirm, because However Is that correct? Edit: I can also see a problem where the |
Right, in In And we can't change the behavior when nesting, either: in Finally, MQs are defined to be either true or false at the rule level, and this is reflected in the APIs that use them. If they start imposing truth or falsity on individual contained rules (like |
I believe the rationale against allowing custom properties was because custom properties are applied against elements, not at-rules that aren't attached to any element.
But now that we can nest at-rules inside selectors, shouldn't we then allow custom properties for nested at-rule conditions?
As for why we can't just use the proposed author
env()
variable, it's because we can't dynamically change it per element.Example of a Flexbox component with dynamic breakpoint set via inline style (which is not possible with
env()
):The text was updated successfully, but these errors were encountered: