Managing the Transition CSS Property at Scale
The transition CSS property is something that I don't see talked about often and yet it's one of the more difficult places to keep things consistent. If you're working in a larger codebase, especially with enterprise web software like me, it's easy for things to become inconsistent and seem impossible to apply constraints to. I chalk this up to a few different reasons:
- In a situation where you need to add an additional transition property when one is already set, you need to remember to re-apply the previous transition property otherwise it will be overwritten.
- the transition property inherently includes every other CSS property
- the transition property handles a few different values that you might want to modify for different contexts (delay, duration, timing, property being transitioned, etc)
I have seen times where people defined a specific timing property in a variable and reused that but I think that might be too restrictive. You can have a fast transition on a
color property but if you want to add a transition to
transform you might want to make that timing longer so that the change is still perceptible to a user.
Instead, I have a different approach using a map and a mixin. The first thing we want to do is make writing out the transition property easier for other developers that you work with. Ideally, it should be as simple as this:
Now that we have our end goal in mind, let's set that up:
This let's us iterate through the list of css properties we want to animate and apply a
100ms duration and
ease for the timing-function. This is great! Developers can rely on a consistent mixin that manages duration and timing for them, all they need to do is specify the property they want to add a transition to.
Unfortunately we still have the problem of wanting different duration and timing properties for different CSS properties. Let's take another look:
Now we have a way to dictate custom durations and timing functions on a per-property level. Whenever a css property is used that isn't already mentioned in the map, the default values are used instead. There is one more thing I think we can add here. After all, there are some CSS properties that we should really avoid ever animating because of it's browser performance. That isn't something that's easy to catch usually and now that we have a mixin for managing transitions we have the opportunity to manage that too.
And that's it. Now, we can dictate custom attributes on a per CSS property basis, provide a helpful error message when developers include CSS properties with poor performance or isn't supported (or use
@warn if we don't want to be too harsh), and establish a malleable future-proofed approach to make the transition property easier to work with moving foward. Now that everything has come together let's look at that original example in the fig.1 gist using what we have built and see what the output looks like: