[csswg-drafts] [selectors] [css-transitions-2] `starting-style` pseudo-class (#10356)

brandonmcconnell has just created a new issue for https://github.com/w3c/csswg-drafts:

== [selectors] [css-transitions-2] `starting-style` pseudo-class ==
## Related specifications & authors

* [css-transitions-2](https://drafts.csswg.org/css-transitions-2)
  * @dbaron
  * @birtles
* [selectors](https://drafts.csswg.org/selectors)
  * @fantasai
  * @tabatkins

## Introduction
I've received valuable feedback regarding the complexity of an `--open` switch [I used to demonstrate `@starting-style`](https://x.com/branmcconnell/status/1791968584836481189) (shown below), which I employed to avoid redundant styles.

```css
dialog {
  --open: 0;
  --closed: calc(1 - var(--open));
  transform: translateY(calc(var(--closed) * -50%));

  &, &::backdrop {
    --duration: calc((var(--open) * 0.5s) + (var(--closed) * 0.25s));
    transition: all var(--duration) ease-out allow-discrete;
    opacity: var(--open);
  }

  &[open] {
    --open: 1;
  }

  @starting-style {
    &[open] {
      --open: 0;
    }
  }
}
```

This way, I could set up my styles in one place and control the open/closed state via a single variable. However, as I added more styles to my state, I found myself having to duplicate them into `@starting-style` each time.

## Problem Statement
While `@starting-style` is undeniably powerful and allows for granular control, it often requires redundancy even for simpler use cases. Consider the following example, the same as above but without the variable trick:

```css
dialog {
  transform: translateY(-50%);
  &, &::backdrop {
    transition: all 0.25s ease-out allow-discrete;
    opacity: 0;
  }
  &[open] {
    transform: translateY(0);
    &, &::backdrop {
      transition-duration: 0.5s;
      opacity: 1;
    }
  }
  @starting-style {
    &[open] {
      transform: translateY(-50%);
      &, &::backdrop {
        opacity: 0;
      }
    }
  }
}
```

In this example, the closed-state styles are duplicated inside `@starting-style`. This duplication becomes more apparent when animating from a custom set of closed-state styles to the default open-state styles:

```css
dialog {
  transition: all 0.25s ease-out allow-discrete;
  &:not([open]) {
    transform: translateY(-50%);
    &, &::backdrop {
      opacity: 0;
    }
  }
  @starting-style {
    &[open] {
      transform: translateY(-50%);
      &, &::backdrop {
        opacity: 0;
      }
    }
  }
}
```

The styles inside `@starting-style` are often the same as the closed state but must still be duplicated for the engine to recognize them. This is where I believe there is an opportunity to simplify the process.

## Proposed Solution
I propose introducing a pseudo-class counterpart to `@starting-style` to eliminate the need for duplicating styles:

```css
dialog {
  transition: all 0.25s ease-out allow-discrete;
  &:not([open]), &[open]:starting-style {
    transform: translateY(-50%);
    &, &::backdrop {
      opacity: 0;
    }
  }
}
```

This syntax informs the engine about the state it is animating from without requiring the developer to duplicate styles. If we want to set styles for the open state as well, we can do so like this:

```css
dialog {
  transition: all 0.25s ease-out allow-discrete;
  &:not([open]), &[open]:starting-style {
    transform: translateY(-50%);
    &, &::backdrop {
      opacity: 0;
    }
  }
  &[open] {
    transform: translateY(0);
    &, &::backdrop {
      transition-duration: 0.5s;
      opacity: 1;
    }
  }
}
```

## Conclusion

By introducing a pseudo-class `:starting-style` counterpart to `@starting-style`, we can avoid requiring developers to redeclare styles "before-state" styles inside `@starting-style`. This proposal aims to improve the developer experience and make `@starting-style` more approachable for simpler use cases while retaining its power and flexibility for more complex scenarios.

---

<details><summary>Some related notes re <a href="https://github.com/w3c/csswg-drafts/issues/9350">CSS Mixins</a> (TL;DR: they don't solve this problem)</summary>
<p>

While [CSS Mixins](https://github.com/w3c/csswg-drafts/issues/9350) will simplify the process of managing styles for different states, I believe this enhancement would be most valuable as an addition to `@starting-style` itself, included in the `selectors` spec. It provides a more straightforward solution for common use cases, reducing redundancy in CSS code and making it easier for developers to define and manage animations between states.

The below examples all assume these mixins are present:

```css
@mixin --dialog-closed {
  transform: translateY(-50%);
  &, &::backdrop { opacity: 0; }
}

@mixin --dialog-open {
  transform: translateY(0);
  &, &::backdrop { opacity: 1; }
}
```

Even using CSS Mixins, the mixins would still need to be invoked again within `@starting-style`:

```css
dialog {
  @apply --dialog-closed;
  &[open] {
    @apply --dialog-open;
  }
  @starting-style {
    &[open] {
      @apply --dialog-closed;
    }
  }
}
```

Now, with `:starting-style` and mixins:

```css
dialog {
  &, &[open]:starting-style {
    @apply --dialog-closed;
  }
  &[open] {
    @apply --dialog-open;
  }
}
```

</p>
</details>

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10356 using your GitHub account


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

Received on Monday, 20 May 2024 17:54:12 UTC