- 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