Open meduzen opened 4 years ago
What I currently do is set the values that go in cubic-bezier
as custom properties at root level and then call cubic-bezier
on them.
:root{
--app-easing-1: .5, 0, .5, 1;
--app-easing-2: 0.55, 0.085, 0.68, 0.53;
}
.some-time-later{
animation: rollOver 1s cubic-bezier(var(--app-easing-1));
}
.some-transition-later{
transition: transform .5s cubic-bezier(var(--app-easing-2));
}
Interesting! By proxying the name of an easing variable, this could also lead to the use of a SCSS function to keep the syntax short:
:root{
--ease-in-quad: cubic-bezier(.55, .085, .68, .53);
--app-easing-2: var(--ease-in-quad);
}
.my-class {
transition: transform .5s cb(2); // supposing all easings are prefixed `app-easing-`
}
could generate:
.my-class {
transition: transform .5s cubic-bezier(var(--app-easing-2));
}
How to better write easings using CSS or SCSS?
I want to improve the way I write CSS
cubic-bezier()
timing functions. I’d like to request ideas and opinions 🙏, and share a few ideas. What does (or doesn’t) work for you, and why?What I do now
What I’ve always done is using a variable coming from the SCSS library Bourbon:
which outputs:
It’s rather straightforward, but I’d like to replace this by using something else, more modern/powerful/straightforward.
It can use SCSS, PostCSS, or both, but it has to be framework agnostic.
Three types of solutions
Existing ideas:
:root
level.ease()
function requiring to writetransition: transform .3s ease(easeInOutQuad);
.transition: transform .3s ease-in-out-quad;
to transform it using the matchingcubic-bezier
value (camelCase also works:easeInOutQuad
).So, three types of solutions: custom properties, a SCSS function, and a PostCSS plugin.
There are various improvements that could be made to each. One of them is getting rid of the
ease*
prefix in order to shorten the syntax:Maybe one of the three type of solutions could fit as a good basis. But maybe shortening the syntax is only one part of the possible improvements and considerations that can be tackled.
More
(done ☑️) Reverse easings
See Reversing an easing curve. It’s powerful and important. I have not seen reversed easings in a library, yet, and I think it could easily be integrated in whatever solution.
(done ☑️) Pulling the package
Supposing a SCSS package, I’d probably want:
This single
@import
would output all the easings available, this way:Alternatively, a partial import could be a solution:
(done ☑️) Custom props and backward compatibility
A flag could exclude/include legacy output. Example with SCSS:
With
$awesome-easing-legacy
, the CSS output should be:(Alternatively, postcss-preset-env is a better solution.)
Naming from the JS world
GSAP names easings differently:
quad
isPower1
;cubic
isPower2
;quart
isPower3
;quint
isPower4
;But the following names are shared:
sine
,expo
,circ
,back
.That’s interesting because PowerX are named according to the math behind their curves (minus 1), and such a naming is very convenient to shape the acceleration/deceleration power of their curves.
So maybe it could be a good idea to alias
quad
topower1
, for example.Splitted easings
Instead, a function could fit another purpose, like splitting an easing curve into several curves at specified breakpoints. This is inspired by split ease, a JavaScript function inserting a linear gap between the acceleration and the deceleration of an easing curve. So maybe this could give an idea for a useful function.
It could look like this:
Other idea: allowing easings to receive a cx (article).
CSS utility classes
I don’t have any interest or need, but who knows… Does someone have a good use case for this?
Of course, all of these shouldn’t prevent you to directly play with your custom easing curves using the dev tools.