Re: [csswg-drafts] [css-variables?] Higher level custom properties that control multiple declarations (#5624)


I'm new here but I would like to give feedback on this proposal that seems a powerful way to achieve many things in CSS. I would also like to stress to participants that CSS improvements can be used in other areas than custom components, and those use cases should be considered as well.

There is a number of features that I find interesting in the `@if` proposal:

- It is scoped inside selectors, and can use custom properties (unlike media queries which also allow conditionals, but only on media features)
- it contains properties (unlike `cond()`) which allows to avoid defining a default value for the properties that are set
- it can be used to implement native CSS mixins, which is what a lot of people were expecting from the `@apply` spec which is now abandonned.

For example, here is how I would use it for mixins:

* {
  @if(var(--mixin-danger) = on) {
    background-color: red;

#my-error-message {
  --mixin-danger: on

As for naming, I would not use `@if` but rather `@when` because `@if` calls for a `@else` and `@elseif` which can complexify the syntax (elseif condition implicitly contains a negation of the conditions defined before, I'd prefer it to be explicit).

Also, would such condionals be allowed to be nested ?

> Edit: Oh, actually, if we define this as just sugar for inline if(), then we can use any value and it's interpreted in the context of each property inside the block. The equality question still stands.

This would bring surprising behaviour where a property in your conditional could be applied but not the next one because the conditional applies differently to it.

I think the sanest approach would be to compare string equality and only allow comparison on types that are independent of the context. If you define `--color1: #f00` and `--color2: red`, then `@if var(--color1) = var(--color2)` would be false. If we want to be able to compare colors, then perhaps we can have a function that would take a color expression of any form and return a standardized value that can then be compared.

If you allow colors to be compared, then you'll get a problem when a custom property contains something that can be interpreted as a color but is not meant to be a color. it could have an equality match with a value where this is not expected.

GitHub Notification of comment by mildred
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Monday, 14 December 2020 14:17:03 UTC