Re: [csswg-drafts] [css-conditional-4] Rename @when to @if (#6684)

I appreciate the discussion, and wanted to share that I am not opposed to either `@if` or `@when`.

I am softly, **less** in favor of `@if`, and I phrase it that way on purpose.

When I’m writing JavaScript or any scripting language with `if` blocks, then I expect the `if` statement to be evaluated only when the higher closure is being evaluated.

**Example 1**: the `if` evaluates when the highest closure — the global, top-level scope — is evaluated.
```js
if (is_truthy) doThis()
```

**Example 2**: the `if` evaluates when the highest closure — the `runThis` function — is evaluated.
```js
const runThis = () => {
  if (is_truthy) doThis()
} 
```

In either example, I do not expect `doThis()` to run if/when something else changes the value of `is_truthy`.

This is the reason I softly, **less** in favor of `@if` for CSS, because I do not share the “if” model. I especially do not share the same “if” model for anything related to media conditions. But that’s me. I’m sharing this in case it maps well for others. If it is ignored or refuted; that’s okay, too.

I want to briefly share how I _positively_ map CSS conditionals to concepts in JS. I mentally map them to listeners, observables, and callbacks.

```js
matchMedia('(min-width: 600px)').onchange = doThis;

matchMedia('(min-width: 600px)').addEventListener('change', doThis);

new ResizeObserver(doThis);

class extends HTMLElement {
  connectedCallback() {
    doThis(this);
  }
}
```

A term like `@when` works for me because I understand it, and it doesn’t conflict with my model for `@if`.

I’d survive if it were called `@matches`, too. :)

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


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

Received on Sunday, 27 March 2022 14:48:32 UTC