Re: [csswg-drafts] [css-animations] The "via" keyframe selector (#6151)

@LeaVerou that's a great idea! The syntax looks a bit weird to me, but I suppose we can't really accomplish that idea without new syntax. I thought first that separating the values with `/` rather than `;` would be nice, but that wouldn't actually work for properties that already use it (e.g. animating `border-radius` that has values containing slashes). Then I thought a function could work, like `opacity: animate(0, .7);` but that causes issues when you're animating values that already use commas.

@birtles makes a good point as well. We can define a `Keyframe` object in JavaScript in such a way already, and so it would be nice to align CSS with this. I thought initially that that would mean the original proposal for `via` should be replaced with something that aligns `@keyframe` definitions more with JavaScript keyframes, but actually `via` is already a step in that direction. Specifically, it would give us this (from [MDN's page on Keyframe formats](https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API/Keyframe_Formats#:~:text=It%20is%20not%20necessary%20to%20specify%20an%20offset%20for%20every%20keyframe.%20Keyframes%20without%20a%20specified%20offset%20will%20be%20evenly%20spaced%20between%20adjacent%20keyframes.)):

> It is not necessary to specify an offset for every keyframe. Keyframes without a specified offset will be evenly spaced between adjacent keyframes.

This would be exactly what `via` would accomplish. The only difference here is that in JavaScript, your keyframes must be [in the right order](https://www.w3.org/TR/web-animations-1/#:~:text=The%20list%20of%20keyframes%20is%20sorted%20in%20ascending%20order%20by%20computed%20keyframe%20offset.) whereas CSS allows you to define them in any order you want.

Anyway, while I do really like the concept of being able to "invert" the keyframe definition as LeaVerou suggested, I would again lean towards that being a separate proposal. That and this proposal are similar and obviously related but solve slightly different use cases. Let me illustrate this with an example:
``` css
@keyframes wiggleThenRainbow {
    0% { left: 0; }
    10% { left: -10px; }
    20% { left: 10px; }
    30% { left: -10px; }
    40% { left: 0; color: black; }
    55% { color: red; }
    70% { color: blue; }
    85% { color: yellow; }
    100% { color: green; }
}
```
This animation is hard to write with inverted notation (if even possible at all) but would benefit from `via`. In particular, `10%`, `20%` `30%`, `55%`, `70%` and `85%` could be replaced by `via`. Then, you could _just_ change the `40%` to adjust where the wiggling ends and where the rainbow starts. It also allows you to much more easily add or remove a wiggle or rainbow color.

However the inverted syntax would be very useful for cases like this:
```css
@keyframes wiggleAndRainbow {
    0% { left: 0; color: black; }
    20% { color: red; }
    25% { left: -10px; }
    40% { color: blue; }
    50% { left: 10px; }
    60% { color: yellow; }
    75% { left: -10px; }
    80% { color: green; }
    100% { left: 0; color: black; }
}
```
You could, in this case, use `via` if you wanted, and write
```scss
@keyframes wiggleAndRainbow {
    from {color: black; }
    via { color: red; }
    via { color: blue; }
    via { color: yellow; }
    via { color: green; }
    to { color: black; }

    from { left: 0; }
    via { left: -10px; }
    via { left: 10px; }
    via { left: -10px; }
    to { left: 0; }
}
```
That would, similar to the previous example, simplify adding or removing a wiggle or rainbow color, though the inverted syntax would most definitely make more sense than `via` here. Either way, these two examples demonstrate the difference in use case for `via` and the inverted syntax.

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


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

Received on Monday, 10 January 2022 10:19:16 UTC