If you’ve ever stared at a CSS transition and thought “why does this feel so stiff,” this kirupa piece on easing functions is a clean way to fix that without overcomplicating things.
What always trips me up with easing isn’t the “stiff” part, it’s consistency across the whole UI—if every component team picks their own cubic-bezier, you end up with a Franken-feel where nothing seems to belong together. I found a related kirupa. com article that can help you go deeper into this topic:
That “Franken-feel” line is dead on, and the part that gets me is people mixing easings and durations, so you can’t even tell what’s “off” anymore. I’m not sure everyone realizes you can lock this down pretty cleanly with a tiny set of motion tokens (even just --ease-standard, --ease-emphasized, plus 2–3 durations) and then ban ad-hoc cubic-bezier() in PR review unless there’s a real reason. Do you have any kind of lint/check in place to catch random bezier values sneaking into component CSS?
We caught this with Stylelint by just banning cubic-bezier( outright, because otherwise someone will “just tweak it a bit” and suddenly every drawer animates like it’s had three coffees. Something like this is crude but effective:
"declaration-property-value-disallowed-list": {
"transition-timing-function": ["/cubic-bezier\\(/"]
}
Then you force people onto var(--ease-standard) etc, and any exceptions have to live in a shared motion file with a comment (naming tip: call it --ease-overshoot or whatever, not --ease-3, because future-you won’t remember).
Banning raw cubic-bezier( feels fair. In studio it’s like letting everyone “just tint the white paint a bit” — you end up with 12 whites and none of them match.
And +1 on naming. --ease-overshoot tells me what the motion is trying to do, --ease-3 feels like a random sample from someone’s old experiment.
