- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Sat, 24 Jun 2017 13:00:42 +0000
- To: public-css-archive@w3.org
> There are at least two easy cases where steps() is very bad: > 1. A one-shot animation not intended to fill. > 2. A repeating animation that doesn't end where it started. I agree that these are the two cases where the `frames()` notation makes most sense. I'm just not sure if we should prioritize these two situations to the point of breaking consistency with the existing set of functions. Perhaps if they represented the overwhelming majority of animations that prioritization would make sense, but I'm not sure they do. For a start, they can never occur with transitions. > It's the ultimate in prioritizing the math over the UX That's not a fair characterization. On the contrary, this proposal is entirely motivated by UX. That is, I've stood in front of developers and tried to explain why these two effects that are nearly identical have completely different names and different numbers and it was awkward. I'd rather say, "You know how this `steps()` thing doesn't do what you want in this particular situation so you're adding extra keyframes and delays and so on--well, now you can just change the keyword at the end and you're done." Besides, I'm really bad at math so I'm hardly going to prioritize it! Anyway, I'm not going to push this anymore. I just felt that the argument for extending `steps()` needed to be made. I still think it will be unfortunate to stick with `frames()` but if no one else feels likewise I guess this will just ride the trains and join the rest of the interesting features in the platform and I'll refine my developer pitch. -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310837198 using your GitHub account
Received on Saturday, 24 June 2017 13:00:48 UTC