declaring nested animations in tailwind.config.js?

[wolfspyre]

so... perhaps I'm just odd;
however I was trying to extend my theme's animation declarations:

tailwind.config.js:

module.exports = {
  theme: {
    ...
    extend: {
      animation: { 
        'grow-left-worky':       'grow-left 200ms 500ms   1 both alternate linear',
        'grow-left-noworky':      { name: 'grow-left', duration: '200ms', timingFunction: 'linear', iterationCount: '1', delay: '500ms' },
      },
      keyframes: {
        'grow-left': {
          '0%': { transform: 'scaleX(0.0)', transformOrigin: 'right'},
          '100%': {transform: 'scaleX(1.0)', transformOrigin: 'right'},
        }, 
      },
    },
  },
},

results in:

TypeError: input.split is not a function
   at parseAnimationValue (node_modules/tailwindcss/lib/util/parseAnimationValue.js:50:28)
   at animate (node_modules/tailwindcss/lib/corePlugins.js:1302:67)

Which afaict is referring to this line in parseAnimationValue.js¹... My question is

Shouldn't one be able to explicitly declare the parameters of an animation, given that the same declaration format is encouraged for keyframes?

From my perspective, it seems like a nice bit of sugar to permit the user to just throw a pile of attributes at the parser and expect it to 'do what I mean' .... (thank you, it really is quite pleasant and friendly)

but I fail to see the downside to of supporting, if not actively encouraging the equivalent declaration syntax of related properties...

I'd imagine it would be (admittedly marginally) faster to consume a blob of kv pairs as named than trying to iteratively invoke voodoo against (reasonably predictable) values and hoping for a match...

Am I missing something really obvious?

Footnotes

1. https://github.com/tailwindlabs/tailwindcss/blob/master/src/util/parseAnimationValue.js#L22 ↩

[wongjn]

Shouldn't one be able to explicitly declare the parameters of an animation, given that the same declaration format is encouraged for keyframes?

As per the line you linked:

tailwindcss/src/util/parseAnimationValue.js

Line 22 in 1648b86

let animations = input.split(COMMA)

The function expects a string, so an object would indeed produce an error as per your original post.

I believe the keyframes format is the way it is because in CSS, it follows a similar pattern:

@keyframes grow-left {
  '0%' {
    transform: scaleX(0.0);
    transform-origin: right;
  '100%' {
    transform: scaleX(1.0);
    transform-origin: right;
  }, 
},

keyframes: {
  'grow-left': {
    '0%': {
      transform: 'scaleX(0.0)',
      transformOrigin: 'right'
    },
    '100%': {
      transform: 'scaleX(1.0)',
      transformOrigin: 'right'
    },
  }, 
},

But this is not the same for animation, which expects a value. This means this equivalent in CSS would be invalid:

.animation-grow-left-noworky {
  animation {
    name: grow-left;
    duration: 200ms;
    timing-function: linear;
    iteration-count: 1;
    delay: 500ms;
  }
}

Though I presume you may wish for it to work like:

.animation-grow-left-noworky {
  animation-name: grow-left;
  animation-duration: 200ms;
  animation-timing-function: linear;
  animation-iteration-count: 1;
  animation-delay: 500ms;
}

Or for Tailwind to flatten the object down all the way down to a single animation shorthand declaration. This seems more like an feature request than a help request at this point.

Am I missing something really obvious?

"Obvious" is a matter of perspective, though I'd say in the utility-based paradigm of Tailwind, there isn't much benefit than to have it in a single animation declaration like grow-left-worky.

If you really wanted the object-based version in your configuration, you could consider flattening the object yourself like:

'grow-left-noworky':
  Object.values({
    name: 'grow-left',
    duration: '200ms',
    timingFunction: 'linear',
    iterationCount: '1',
    delay: '500ms'
  }).join(' '),

Though again, if your point is that Tailwind should do this for you, I feel like this post would have been more appropriate as an 💡Idea post, rather than a 🙏Help post.

[wolfspyre]

Hiya Justin!
A) thanks for the explanation; (really)

If ya notice, grow-left (worky/noworky) were essentially the same... excluding the fact that when expressed in the fashion of 'grow-left-worky' ... it .... uh... works... corespondingly.... noworky... well.... doesn't ;)
I was attempting (and apparently failing) to bring a bit of levity to the conversation,
(as everyone I know is pretty stressed out at the moment, I figured it would be better to be a little on the comical/silly side... sorry if that didn't come across as intended.)

I wholly agree about the way keyframes are declared... I just didn't understand why the two (in my mind) inexorably related constructs didn't support the same manner of attribution/creation in one's tailwind config...

looking at the code that consumes the user's animation declaration from the tailwind config, it grabs each var and subsequently compares that value to a known list of values for different attributes, which, while quick, isn't really the most efficient... and so it struck me as confusing that the preferred method of describing an animation's parameters not be as a series of KV pairs that the user hands parseAnimationValue, as I thought the output of parseAnimationValue was an object

(or at least that's what I inferred looking at the test structs)

Rather than assuming it should work the way I thought was intuitive, I felt that the most respectful way to start the conversation was to begin by asking for help understanding the reasoning behind the current behavior; as It seems reasonable that there's a legitimate design decision that I don't quite grok....

so... I wasn't quite at the point of suggesting my confusion was an idea... but I suppose that's a moot point now, so I'll go ahead and switch the post type, as my intent truly was to NOT ruffle anyone's feathers....

:)
so.... all that being said...

Wouldn't it be more efficient to parse animations if they were declared in tailwind.config.js in the same style as keyframes?

[adamwathan]

The animation-* utilities in Tailwind map specifically the CSS animation property, so the configuration expects the same value that the CSS property expects, which is a space-delimited string. You're right it would be less work internally if that data was passed as an object but then it wouldn't match CSS, so even if we supported that we'd want to support the current version too. I'd be hesitant to support a new syntax personally because it's not something we do anywhere else in the config file, and I feel like it's a bit like opening Pandora's box around future API decisions.

For example, if we did it for animations, why not do it for box shadows?

boxShadow: {
  md: [
    {
      x: "0",
      y: "4px",
      blur: "6px",
      spread: "-1px",
      color: "rgb(0 0 0 / 0.1)",
    },
    {
      x: "0",
      y: "2px",
      blur: "4px",
      spread: "-2px",
      color: "rgb(0 0 0 / 0.1)",
    },
  ],
}

TL;DR though the answer to your question is just "because that's what CSS does for that property" 👍