- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Dec 2023 16:45:07 +0000
- To: public-css-archive@w3.org
@bramus:
> One downside though, is that you’re then limited to either effect-timings or either keyframe-timings – you can’t have both. Not sure if that’s a limitation that would bother most people or not.
That's a good point. I'm trying to think about use-cases but can't think of any.
I guess authors could as well do something like:
```css
* {
animation-timing-function: linear;
}
```
And then only work on `animation-easing`. That could leave the option to have both maybe?
@flackr:
>> How would setting the iteration-wide easing inside a keyframe work? Would it reset the progress from that point? If not, what use-cases would that serve?
>
> It would not be a valid property inside a keyframe, like other animation affecting properties.
Yes, that was my thought.
> If we used auto, I'd propose it is only specified through omission.
Right, that sounds good, still leaving us with the shorthand problem.
> I'm a bit confused here. If animation-easing is unspecified, then the animation easing will be linear (as it is today), and the animation-timing-function will have its default ease value unless another is specified by the developer. If the developer sets animation-easing: linear my thinking was that we would want to then replace the initial animation-timing-function: ease value with animation-timing-function: linear as well to respect the specified linear. This requires that the initial "linear" value and the specified "linear" value are handled differently.
OK, I wasn't sure this is possible via an unspecifiable/ommitted `auto`, but I guess we're on the same page now.
-----
To sum it up, I think we have an agreed way forward for reseting keyframe-wide to `linear` behavior. It's just the shorthand that's still an issue.
--
GitHub Notification of comment by ydaniv
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6982#issuecomment-1856189039 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 December 2023 16:45:08 UTC