[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

[ulken]

Haven’t thought too much about it, but would a mix of 1. and 2. be possible?

Keeping keyframes a separate plugin but have animations depend on it? Would be nice to only have to import one plugin if you’re not after the fine-grained control.

Both syntaxes would need to be supported too then, I guess. Maybe too complex. Just throwing it out there.

[mcourtier]

Approach 2 mirrors the original CSS fashion, I like it. And it’s more readable.

[OwenMelbz]

Option 1 is nicer in the sense it’s contained. And you only need to focus on reading 1 thing.

It also makes it easier to package animations as you can just do like...

animation: [...require(“animation-library”)]

Option 2 looks nicer as there’s not a mixture of structures in the definition.

Option 1 seems more re-usable as you can just create a variable with your definition, then plug it in where it fits. Whereas Option 2 is based on the assumption key/property names match up.

Although Option 2 looks nicer (Whilst there’s minimal code), I’d probably lean towards Option 1 on the re-usability front

[michaelhays]

It is nice keeping the animation and keyframes in the same place. Maybe something like this would make Option 1 more reusable:

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

[bartveneman]

For projectwallace.com I figured that there are two important configs to animations and transitions: duration/delay and the timing function. Perhaps these could be configurable at the theme level and the rest at the config level? Or would that become too complex?

[koresar]

As someone who don't speak CSS I'd vote for option 1. Reasons:

• I have no idea how to combine transition and animation. I'm dumb.
• We can sorta have option 2 via modifiers a-la ":fast" or suffix a-la "-fast"/"-faster"/"-fastest" etc.
• Option 1 will be configurable regardless via the tailwind.js config file. So, the need in option 2 decreases.

But, why not both? (C)

[royvanv]

Approach 2 makes the most sense to me, both its syntax and reusability are better in my opinion.

[victorgarciaesgi]

I think Option 2 is better, it's more readable on more maintainable.
Could it also affect childs, like used in @tailwind/typography plugin?
Like:

{
  keyframes: {
    spin: {
      from: { 
        transform: 'rotate(0deg)',
        '.child': {
          opacity: '0'
        }
      },
      to: { 
        transform: 'rotate(360deg)',
        '.child': {
          opacity: '1'
        }
      },
     
    }
  }
}