Re: [csswg-drafts] [css-values-5] What is the MVP for inline conditionals on custom properties? (#10064)

The syntaxes proposed and discussed here all echo the most criticized "bad practice" patterns in other languages - in my opinion, we need to think harder about the syntax and come up with something that doesn't do that.

If we push for something like this out of impatience, there's a good chance we're making the situation irreparably worse, in the sense that any future syntax attempting to address the problems and shortcomings of an early syntax will need to be backwards compatible, which really narrows our options - which are already narrow.

That said, why are we trying to force this into property-level conditionals?

Wouldn't it make more sense to take cues from established and popular languages such as SASS, where conditionals are *structural* concepts? CSS is really all about thinking and designing in terms of structure.

Something in this direction would be immediately easy for almost anyone to understand:

```css
.element {
  /* Base styles */
  font-family: sans-serif;
  color: black;
  
  /* Conditional block */
  @if (--theme == 'dark') {
    color: white;
    background-color: #333;
  } @else if (--theme == 'light') {
    color: #333;
    background-color: #f0f0f0;
  } @else {
    /* Default theme */
    color: #444;
    background-color: #e0e0e0;
  }
  
  /* Media query integration */
  @if (media(min-width: 768px)) {
    width: 750px;
  } @else {
    width: 100%;
  }
  
  /* Nested conditions */
  @if (--layout == 'grid') {
    display: grid;
    @if (media(min-width: 992px)) {
      grid-template-columns: repeat(3, 1fr);
    } @else if (media(min-width: 768px)) {
      grid-template-columns: repeat(2, 1fr);
    } @else {
      grid-template-columns: 1fr;
    }
  }
}
```

It's a bit more verbose, but a lot more readable and less *cramped* than trying to force complex expressions to fit into property values, I think? It also accounts better for situations where you want the same condition to control two alternative properties - that's already common with things like media queries, and I'm betting you would find, in practice, the same requirement would exist here.

I understand there is a potential for creating cycles with a feature like this, but... developers should know not to do that. 😅

And it's not too difficult to think of a relatively simple approach to mitigate that problem, without resorting to complex static analysis or ugly runtime checks like cycle prevention - for example, maybe we specify a simple two-phase evaluation, such that:

1. CSS properties are updated in the first phase, and
2. custom properties are updated in a second phase.

So to illustrate, consider an example like this:

```css
:root {
  --theme: 'light';
}

.element {
  @if (--theme == 'light') {
    background-color: #333;
    --theme: 'dark';
  } @else {
    background-color: #fff;
    --theme: 'light';
  }
}
```

In terms of execution, it would work something like this:

```css
.element {
  /* PHASE 1: Condition evaluation */
  @if (--theme == 'light') {
    background-color: #333;
  } @else {
    background-color: #fff;
  }

  /* PHASE 2: Property modifications */
  @if (--theme == 'light') {
    --theme: 'dark';
  } @else {
    --theme: 'light';
  }
}
```

In other words, you can update custom properties, but only for the purposes of using those values in CSS properties - it's not going to cascade or have any impact on other conditionals.

If users do attempt to write CSS with cascading conditional effects, in addition, perhaps the browser would issue a warning, letting them know they're getting a previous custom property value in their conditionals, rather than the updated value.

Full disclosure: *I'm not at all certain about this idea*, just putting it out there. 😅


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


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

Received on Sunday, 21 July 2024 10:55:42 UTC