CSS Transitions

[inxilpro]

This PR introduces a handful of CSS transition utilities. See the discussion at #14. It's mostly just a few new generators and updated docs/tests/etc, but it also includes a fix to the variants-and-disabling partial that allows for no variants.

• Generators
• Config
• Docs
• Tests

[fedetibaldo]

Transitions are a necessary feature. I have some feedback though.

Isn't transition quite long to write? I mean, the whole library tends to abbreviate class names, and your first approach (see #14) clearly had brevity in mind. I implemented some transition utilities in my codebase too, and I was frankly quite delighted when I saw that you used the same prefix (trans) on the previously cited issue as well. From my perspective, the ladder would be a better alternative to the officially proposed naming convention.

[inxilpro]

Sure, I’m definitely open to calling it trans — does anyone disagree?

[TVke]

I would think everything is accessible with one or two letters only when unclear the full so maybe ts.

[fedetibaldo]

Don't know... Widths, margins and paddings are easily accessible with very few letters because you use them very often, and once you learn the shorthand, you never forget it.

Transitions are not the same thing in my opinion. They are more similar to borders: you don't use them that much, so it doesn't bother you to write it down in full. On the other hand, it does bother you having to learn a new abbreviation or having to take a look at the documentation everytime you forget what the said abbreviation is.

trans seems like a good compromise. Moreover, I instinctively wrote it like that, as @inxilpro did as well.

[inxilpro]

I agree with @fedetibaldo. If it's going to be abbreviated, I think trans is clear while being concise.

[inxilpro]

I just updated the PR. There was one other place where I would like feedback on. The timing function classes right now are:

.trans-linear
.trans-ease
.trans-in // ease-in
.trans-out // ease-out
.trans-in-out // ease-in-out

I could see an argument for:

.linear
.ease
.ease-in
.ease-out
.ease-in-out

Thoughts?

[fedetibaldo]

What do you mean by the second snippet? Dropping the trans- prefix, adding ease- before the name of the timing functions or both as you have written?

In either case, I'm really against dropping the prefix when talking about something related to transitions. The ease addition is just personal taste. I honestly prefer it, but I can just tweak the settings and adopt it, so it doesn't bother me.

[inxilpro]

Well, the transition timing function names are pretty unique, so they don't necessarily need to be prefixed. So you could do something like:

<div class="trans ease-in-out">This will transition using the ease-in-out timing function.</div>

Versus (with prefix, but shorter class names):

<div class="trans trans-in-out">This will transition using the ease-in-out timing function.</div>

Versus (the most verbose):

<div class="trans trans-ease-in-out">This will transition using the ease-in-out timing function.</div>

[TVke]

The trans prefix is needed because maybe later an animate class could be added and that has an timing-function as well.

[inxilpro]

@TVke good point. How do y'all feel about trans-in vs trans-ease-in? Originally, I liked the shorter names, but after looking at it, I feel like mapping the names to the timing functions is probably easier for most people. Especially since this is a feature that people won't be reaching for a ton, it's probably better to give names that are easy to guess at (i.e. the same as the timing function name).

[fedetibaldo]

I prefer the verbose style

[inxilpro]

Yeah, I convinced myself. Updated the PR. Here's the current summary of generated utilities:

// Default
.trans { 
  transition-duration: .25s;
  transition-property: all;
  transition-timing-function: ease-in-out;
}

// Duration
.trans-slower      { transition-duration: .75s; }
.trans-slow        { transition-duration: .5s; }
.trans-fast        { transition-duration: .15s; }
.trans-faster      { transition-duration: .075s; }

// Properties
.trans-all         { transition-property: all; }
.trans-none        { transition-property: none; }
.trans-bg          { transition-property: background; }
.trans-opacity     { transition-property: opacity; }
.trans-color       { transition-property: color; }
.trans-shadow      { transition-property: box-shadow; }

// Timing Function
.trans-linear      { transition-timing-function: linear; }
.trans-ease        { transition-timing-function: ease; }
.trans-ease-in     { transition-timing-function: ease-in; }
.trans-ease-out    { transition-timing-function: ease-out; }
.trans-ease-in-out { transition-timing-function: ease-in-out; }

[TVke]

@inxilpro quick question what about transition-delay?

[fedetibaldo]

You have point. If we are going to implement transitions, adding all the properties would make sense.
I'd suggest something like

.trans-delay-none {
    transition-delay: unset;
}
.trans-delay-1s {
    transition-delay: 1s;
}

In my opinion, transition-delay gets used very rarely, so some fillers are the only thing we need.

[inxilpro]

Sure. Added:

.trans-delay         { transition-delay: 100ms; }
.trans-delay-long    { transition-delay: 200ms; }
.trans-delay-longer  { transition-delay: 300ms; }
.trans-delay-longest { transition-delay: 400ms; }
.trans-delay-none    { transition-delay: unset; }

(Updated to reflect shorter delays).

[inxilpro]

I thought I'd add a few variants so you could do something like:

<div class="group">
  <div class="trans trans-delay group-hover:bg-grey">1</div>
  <div class="trans trans-delay-longer group-hover:bg-grey">2</div>
  <div class="trans trans-delay-long group-hover:bg-grey">3</div>
</div>

…if you wanted the backgrounds to fade in with a little variation. I'm not sure that the .25s intervals is right, though. Anyone actively use delays that could comment? It may make sense to just do 100ms or even 50ms intervals—most of the time, these delays will be to add just a little character to transitions, I imagine.

[inxilpro]

Updated the delays. This looks better to me:

[adevade]

Can't wait for this PR! Good job!

Just a question. Why use s for durations and ms for delays?

[m1guelpf]

I don't know if Adam has reviewed this yet (at least he hasn't commented), so I'd say you should ask for his oppinion on the current changes before adding more things...

[adamwathan]

Hey all! Haven't chimed in on this PR because I've been focused on getting the plugin system out the door.

I'd really like to get transitions into core eventually but I'm not ready to really dig into it to make sure we nail it before getting it into a release right away.

@inxilpro What do you think about releasing this as a plugin in the mean time so it can be iterated on separate from the framework itself, and once it feels like the API is perfect we can transition it into core? I'll be tagging 0.5.0 with the plugin system this afternoon.

[inxilpro]

@adamwathan Sure, I'm game. Any plans for an official plugin list/repo/etc?

[inxilpro]

Here's a basic plugin — anyone want to give it a shot?

https://github.com/glhd/tailwindcss-plugins

[adamwathan]

@inxilpro Cool! Sorry I should have mentioned this but the plugin system that's currently available in 0.4.3 won't work quite the same way in 0.5.0, namely the rule function you're using has been entirely removed in favor of the cleaner object syntax you originally suggested:

#412

I'm just working on the release notes/upgrade guide for 0.5.0 right now and will be tagging it shortly.

[inxilpro]

@adamwathan Got it. Updated the plugin to reflect those changes.

Basically, just yarn add glhd-tailwindcss-transitions and then add it to your Tailwind plugins. The module is an es6 module, which I may change so that you don't have to use default, but right now you'll either have to import transitionsPlugin from 'glhd-tailwindcss-transitions' and then add transitionsPlugin() to your Tailwind's plugins config, or do something like require('glhd-tailwindcss-transitions').default(). I may tweak that shortly.

[knowler]

I am hesitant about the trans- prefix. Though the above mentioned conflict with transform makes it potentially confusing, when using transform one would usually first think of scale, matrix, rotate, skew, translate, so I think this argument could be weak. But, there still could be a conflict with translate, which I could see used like trans-x-1/2, trans-y-full, or trans-3d.

Personally, I like no prefix and props- for -property. I’m using the following on a project.

/** duration */
.quicker { transition-duration: .1s; }
.quick { transition-duration: .2s; }
.slow { transition-duration: .5s; }

/** timing-function */
.linear { transition-timing-function: linear; }
.ease { transition-timing-function: ease; }
.ease-in { transition-timing-function: ease-in; }
.ease-out { transition-timing-function: ease-out; }
.ease-in-out { transition-timing-function: ease-in-out; }

/** delay */
.delay-short { transition-delay: .1s; }
.delay-long { transition-delay: .2s; }

/** property */
.props-all { transition-property: all; }
.props-transform { transition-property: transform; }
.props-colors { transition-property: background-color, color; }
.props-color { transition-property: color; }
.props-bg { transition-property: background-color; }

This approach is also problematic as the durations, timing-functions, and delays would all have corresponding conflicts with animation... and making them agnostic by doubling up the rules (e.g. transition + animation ease timing function in .ease) could be a bad idea?

As much as I dislike it, transition- may be the best to avoid conflicts. Personally, I would opt for the more terse t- (and use a- for the animation classes).

[inxilpro]

@knowler You can configure it however you want. Just install the plugin from https://github.com/glhd/tailwindcss-plugins

[ricricucit]

why isn't this getting implemented?

[ricricucit]

Not to be too annoying, but @adamwathan why is this not implemented yet?
How can I help to get this merged?

[adamwathan]

why is this not implemented yet?

Because I haven't made the time to work through it yet. Use the plugin if you want the functionality from this PR right now, that's what the plugin system is for?

[inxilpro]

@ricricucit let me know if you need any help getting the plugin working. And @adamwathan — let me know if there’s anything I can do to help, although I imagine it’s just a matter of time, which I sadly can’t help with :) No rush on my part.

[Anachron]

There is only the docs part left right?

[samuelterra22]

Please, fix conflicts and merge branch

[Anachron]

@adamwathan hey how are you doing?
I'd love to get this in the default package so I was wondering if you got less busy in the meantime?
No pressue.

[simensen]

Something isn't sitting right with me using trans as a prefix. I like that the plugin currently has transition- prefix and that it is configurable.

[inxilpro]

Yeah, I agree. I’m pretty sure Adam has planned to tackle this after the 1.0 release, so I just decided to leave it as-is. I’m happy to update it again to better match the plugin, but I’m going to wait until we hear something from Adam about what he’s thinking.

[inxilpro]

There are other CSS properties like transform and translate that conflict, and the class names should be easily discoverable. CSS transitions aren't the type of thing that you're going to use on every element, so I think it makes more sense to favor discoverability over the slight advantage of having to type a few less characters.

[Anachron]

Ok sorry I then have misunderstood the reasoning. I have deleted my comment.

[tyler36]

Just a though. Instead of

.trans-delay         { transition-delay: 100ms; }
.trans-delay-long    { transition-delay: 200ms; }
.trans-delay-longer  { transition-delay: 300ms; }
.trans-delay-longest { transition-delay: 400ms; }

How about something like

.trans-delay-100    { transition-delay: 100ms; }
.trans-delay-200    { transition-delay: 200ms; }
.trans-delay-300    { transition-delay: 300ms; }
.trans-delay-400    { transition-delay: 400ms; }
...
.trans-delay-0        { transition-delay: unset; }

This keeps follows the convention with font-weight & colors while keeping flexibility.

[mrcsmcln]

Figured I'd throw in my $0.02. I'm currently working with the following, taking inspiration from leading-*, tracking-*, and spacing:

{
  durations: {
    shorter: '250ms',
    short: '500ms',
    normal: '1000ms',
    long: '2000ms',
    longer: '3000ms'
  },
  easing: {
    normal: 'ease',
    in: 'ease-in',
    out: 'ease-out',
    'in-out': 'ease-in-out',
    linear: 'linear',
    start: 'step-start',
    end: 'step-end'
  },
  transitionDelay: theme => theme('durations'),
  transitionDuration: theme => theme('durations'),
  transitionTimingFunction: theme => theme('easing')
}

.delay-shorter: { transition-delay: 250ms; }
.delay-short: { transition-delay: 500ms; }
.delay-normal: { transition-delay: 1000ms; }
.delay-long: { transition-delay: 2000ms; }
.delay-longer: { transition-delay: 3000ms; }

.duration-shorter: { transition-duration: 250ms; }
.duration-short: { transition-duration: 500ms; }
.duration-normal: { transition-duration: 1000ms; }
.duration-long: { transition-duration: 2000ms; }
.duration-longer: { transition-duration: 3000ms; }

.easing-normal: { transition-timing-function: ease; }
.easing-in: { transition-timing-function: ease-in; }
.easing-out: { transition-timing-function: ease-out; }
.easing-in-out: { transition-timing-function: ease-in-out; }
.easing-linear: { transition-timing-function: linear; }
.easing-start: { transition-timing-function: step-start; }
.easing-end: { transition-timing-function: step-end; }

So far, it's working fine, especially for custom timing functions (e.g., cubic-bezier). Don't see why this couldn't be applied to transition-property as well, but I haven't gotten around to typing out all those properties. Usually works without specifying the property anyway if the transition isn't too complex.

A word on animations: since there are @keyframes involved, you'll be coding CSS anyway, so I figure it's safe to exclude animation-* from the scope of these class names. On the other hand, I suppose we could do something like this: class="transition duration-short easing-out" and class="animation duration-short easing-out".

Edit: Including animation utility classes alongside transitions (as mentioned above) has been making a lot of sense. Even if you have to write the @keyframes separately, they're highly reusable. I've also been trying this out for durations and it's been working better than keywords:

{
  durations: {
    ms: '1ms',
    '0': '0',
    '1': '50ms',
    '2': '100ms',
    '3': '150ms',
    '4': '200ms',
    '5': '250ms',
    '6': '300ms',
    '8': '400ms',
    '10': '500ms',
    '12': '600ms',
    '16': '800ms',
    '20': '1000ms',
    '24': '1200ms',
    '32': '1600ms',
    '40': '2000ms',
    '48': '2400ms',
    '56': '2800ms',
    '64': '3200ms',
  }
}

So the classes would be more like duration-4 and delay-10.

[sasafister]

Will there be any option for case where I wan to hover on card itself but trigger transition animation on some div inside card?

[hacknug]

Will there be any option for case where I wan to hover on card itself but trigger transition animation on some div inside card?

That's what group variants are for. You can use core's group-hover and if you need to handle this also on focus or active, you can use @benface's tailwindcss-interaction-variants.

Also don't expect this PR to get merged. Adam's been working on his own transitions plugin which should be out they release TailwindUI if I didn't miss anything 👍

[sasafister]

That's what group variants are for. You can use core's group-hover and if you need to handle this also on focus or active, you can use @benface's tailwindcss-interaction-variants.

Also don't expect this PR to get merged. Adam's been working on his own transitions plugin which should be out they release TailwindUI if I didn't miss anything 👍

That's what I'm waiting for, it doesn't make sense to create something like that if Adam is working on this already... :)

[adamwathan]

Superseded by #1273, sorry for not at least getting this merged in and basing my work off of that :/ Really appreciate the contribution either way.