[FEATURE PROPOSAL] utility for animation

[vortechron]

e.g.

<div class="delay-1s duration-2s iteration-infinite">

</div>

[ricricucit]

you might be interested in participating here: #378

[royvanv]

@ricricucit This issue is about animations, not transitions. Although I see some discussion about animations in there too.

I propose animations could be added in the Tailwind config file and be added in the HTML via a class animation-[name].

Config:

// tailwind.config.js
	animations: {
		siren: {
			from: {
				backgroundColor: "red",
			}
			to: {
				backgroundColor: "blue",
			}
		}
	}

Output:

.animation-siren {
    animation-name: siren;
}

@keyframes siren {
  from {background-color: red;}
  to {background-color: blue;}
}

Usage:

<div class="delay-1s duration-2s iteration-infinite animation-siren">

[benface]

@royvanv Until CSS animations are added to Tailwind core, you can use my plugin: https://github.com/benface/tailwindcss-animations

[royvanv]

@benface Funny to see your implementation is the same as my proposal. Not directly looking for animations myself, though.

[benface]

It's similar, but I use different classes for delay and duration, to not conflict with Tailwind's transition classes.

[royvanv]

Hadn't considered the naming conflict, I was just proposing the animation-name property.

[adamwathan]

Planning to add this for sure, API I am thinking is to just use the animation shorthand, since I find it pretty uncommon to reuse an animation with different durations (usually it's just one big complex thing). Just using the shorthand has the benefit of avoiding naming conflicts with the transition stuff too.

Haven't thought about it TOO much but probably something like:

module.exports = {
  theme: {
    keyframes: {
      spin: { from: { transform: 'rotate(0deg)' }, to: { transform: 'rotate(359deg)' } }
    },
    animation: {
      spin: '500ms infinite spin'
    },
  }
}

We could try to get clever with declaring the animation and keyframes in the same place too, just need to think of a way to define it that doesn't feel like it has any risk of regret.

[surjithctly]

+1 for this,

It would be a great addition so that we can create simple animations like loading spinners. (must have for devs)

[adamwathan]

Working on these animation utilities this week and trying to nail down the configuration API...

There are two high-level approaches I can think of:

1. Co-locate the animation and keyframe definitions

We could use a single animation section where you define both the animation properties and the keyframes together, think something like this:

animation: {
  spin: [
    '3s linear infinite',
    {
      from: { transform: 'rotate(0deg)' },
      to: { transform: 'rotate(360deg)' },
    },
  ],
},

Exact syntax subject to change but you get the idea.

2. Separate keyframes configuration

Another approach is to separate the keyframes and animation configuration into separate keys. This is much less clever and much closer to vanilla CSS:

animation: {
  spin: 'spin 3s linear infinite',
},
keyframes: {
  spin: {
    from: { transform: 'rotate(0deg)' },
    to: { transform: 'rotate(360deg)' },
  }
}

In this version, we'd likely have two core plugins: animation and keyframes that both read from their respective keys.

I really can't decide which of these makes more sense. I think there's a good argument for option 2 because "less clever" usually === "less likely to regret" but there's something nice about being able to configure an animation together in a single place.

Anyone have any strong thoughts on this?

[gsimone]

Number two makes it easier to reuse animations with pre-set configurations, something like:

animation: {
  card-enters: 'enter 1s ease-in',
  small-card-enters: 'enter .5s ease-in'
}

[vortechron]

@adamwathan appro 2 looks clean n reusable imo