Fade transition?

[rawcreative]

While it's obvious that flickity is meant to be based on a sliding transition, I was curious if there's any plans on implementing an optional Fade based transition/animation instead of the slide?

I would love to replace my current hand-rolled image galleries/carousels with flickity in my projects both personal and commercial, but many of them use fading transitions instead of sliding. I'd be more than happy to pre-pay for a commercial license/donate/whatever if it helps that get implemented.

[desandro]

Add a 👍 reaction to show your support for this feature. Do not add +1 comments — They will be deleted. Subscribe to the issue using the button in the sidebar.

---

Hi! Thanks for this feedback. No, I do not have plans to add fade transitions to Flickity. This seems like a simple feature, but it would be complex to add. Flickity is designed to work with cells that are laid out next to one another.

If fade transition is a must have featured, I recommend Slick by @kenwheeler, or RoyalSlider

[hellojebus]

This would definitely be a cool option. I've used Slick and it is a great alternative. I'll stick to Flickity in the meantime though.

[hydrotik]

👍 You might consider a feature comparison with Slick as it's a bit unclear what the justification would be to move from the MIT license of Slick to a commercial license with Flickity?

[desandro]

After consideration, Flickity will not add fade animation. Flickity is all about sliding. Fade transitions are a different pattern that would require a lot of re-tooling. Use Slick or RoyalSlider instead.

[hydrotik]

We have been using Slick for some time already. With the great experiences we have had with Isotope, we were excited and quick to explore moving to Flickity with the corporate license. Again, it would be nice to understand the difference between the two (and anything else that is comparable) in making a determination on what will ultimately add more value.

[hydrotik]

Also thought I'd include this in this thread as you took the time to write a thoughtful post on the metafizzy site about the value of the product which I found after my previous comment.

http://metafizzy.co/blog/flickity-v1-released/

And a somewhat related thread on a previous license question #20

[FabianGabor]

If it would be an option to set the slide transition time or completely disable the sliding, the fade animation could be easily solved with css opacity transitions, no need for jquery.

[wgstjf]

+1 on the ability to fade even if it uses css as per @FabianGabor suggestion. With that in place I know I would be able to achieve all my clients' site design requirements with one great 'slider'.

Cheers,

Will

[inlikealion]

+1

[josephbergdoll]

+1

[terkelg]

+1

[StefanEndress]

+1

[paul-straetmans]

+1

[baoagency]

+1

[eikeco]

+1

[aaronstezycki]

+1

[aaronstezycki]

So I've managed to hack around this, and it might be a 'omg don't do that' situation, but meh, I'm not bothered. Here's how I did it (CSS Only):

.flickity-slider{ transform: none !important; }
.slider__item{
    left: 0 !important;
   opacity: 0;
   transition: "opacity 0.3s ease-in-out";
}
.slider__item.is-selected{
    opacity: 1;
}

Voila

[eikeco]

I have taken @aaronstezycki example and reproduced it here:
http://codepen.io/eikeco/full/MwGRKr

It certainly works but I would still recommend Slick or RoyalSlider as @desandro mentioned in his initial reply.

That said, it's a good hack @aaronstezycki :)

[lmartins]

Nice. @aaronstezycki suggestion seems like a viable solution for single item sliders.
Would love to have this feature built in in Flickity, so that I can use just one plugin for all my sliders. Will give this solution a go.

[dustinhorton]

+1

[paulmasek]

+1

[mdmoreau]

The CSS trick seems to work really well @aaronstezycki - nice! The only thing I noticed is that you'll probably want to add a z-index: 1 to .slider__item.is-selected so you can interact with the active slide.

[eikeco]

@mdmoreau I have updated the demo here: http://codepen.io/eikeco/pen/MwGRKr

I set hidden slides to have z-index: -1; and .is-selected to have z-index: 0;. Setting .is-selected to z-index: 1 covers the navigation items. See demo above.

Thanks for the tip :)

[dallanlee]

@leenasekhar I don’t understand. You want a solution like this but for a Slick carousel implementation?

[leenasekhar]

@dallanlee Yes! You are right.

[dallanlee]

@leenasekhar Sorry but I haven't used Slick in a couple years because of a couple limitations. If you have a CodePen for me to look at to get started, I may be able to find some time to tinker with it.

[desandro]

I'm re-opening this issue to gain more feedback.

[gingersoulrecords]

@desandro I've used @dallanlee 's solutions to construct a few instances of fading carousels (for things like testimonials on more fade-y, elegant layouts that don't want quick movements). What other kinds of feedback are you looking for?

[eikeco]

@desandro here's a visual example of what I think we are asking for (based on @aaronstezycki solution): http://codepen.io/eikeco/full/MwGRKr

Of course, it's a hack. I'm not suggesting this is how you implement the feature.

[dallanlee]

@desandro looking at the comments here from the past year, you'll already know my opinion on the matter, which hasn't really changed. If there were to be a JS option to change the carousel's interface type from moving/sliding to fading, I would still welcome it, but I'm not anxious for it.

All it would need to do, IMO, is have no CSS transform on .flickity-slider, set the CSS of .gallery-cell to not have a left value, make z-index: 1 and opacity: 0 while .gallery-cell.is-selected has z-index: 2 and opacity: 1. Which means .flickity-previous-next-button needs z-index: 3. Flickity could then have a starting default transition value on the opacity property that can easily be overwritten with the users own CSS.

But honestly, this hack isn't a problem for me. Calling it a hack gives it a negative connotation. I don't think there's a problem with it other than having to use !important in my CSS to override Flickity's inline styles.

Here's the basic demo you probably saw above where I implemented fading https://codepen.io/dallanlee/pen/GEjWpo.

[desandro]

@dallanlee Thanks for your input here. I appreciate your enthusiasm! This would be a bigger feature because it directly confronts Flickity's positioning behavior. Here are some of the questions I'll need to answer (in addition to the points you raised):

• What about groupCells?
• What about cellAlign?
• What about dragging? What about the scroll event? Does dragging incrementally change opacity moving from one slide to the next?
• Should cells get display: none when they are completely hidden?
• What happens when you remove a cell?

I've got ideas about how to address these. I think it can be done. But like I originally said, this is going to be a complex feature. If I'm going to do it, I'd like to do it right.

---

On top of that, the whole idea of Flickity is that it's flickable. It's is tactile, responsive to movement. Fade transitions with static positioning is antithesis to that. If you want a fade carousel, you don't need Flickity. You can build it mostly with CSS and some light JS.

This feature is just not my cup of tea. But there's been so much interest in it. So I'm mulling it over.

[dallanlee]

@desandro Wow, very good points that I haven't given much thought to. I agree that Flickity isn't the right choice for a fade-only carousel. I've personally done it when the design calls for the same set of slides to be flicked on some screen sizes and faded on others. But I have been very narrow-sighted with the fade use cases based only on my specific needs. I'll take a back seat on this and see what others have to say before I provide more input 😳

[gingersoulrecords]

The reason I liked @dallanlee 's fork was because other carousel plugins (slick, etc) have a 'flash' issue where, during a transition, two slides having opacity values less than 1 causes a 'flash' of the background color. Using his fork, I'm able to achieve a far more elegant 'dissolve' effect, but I do have to override CSS and make sure that my transition speed is quicker than the animation delay.

Given the physics, grouping, and flickability intentions of Flickity, adding a fade option does feel forced. @desandro have you given any consideration to building a separate fading carousel plugin, if it's that simple? I'd use/buy it in a heartbeat.

[gavin310]

What about dragging? What about the scroll event? Does dragging incrementally change opacity moving from one slide to the next?

@desandro It would be pretty cool if dragging would incrementally change the opacity. Or at least having that as an option.

[cmalven]

Since it looks like you're looking for some feedback on this issue, here's my 2 cents…

I would love to have either an official "fade" transition in Flickity, or an easy, officially-supported way to accomplish a fade transition using the API. Some of the solutions posted here work okay, but I'm hesitant to use anything that isn't officially supported and documented by Flickity for fear of it breaking in future updates.

Every project I ever work on has at least one slider, sometimes several of them. I strongly prefer the flexibility, documentation, stability, and API of Flickity over any other option. However, much of the time a slide transition doesn't make sense for the design/animation language of the project. I still want all of the great things Flickity brings to the table, but I have to settle for an alternative just because Flickity includes no supported way to create the experience I'm looking for.

Even worse is when I have one slider experience on the site where Flickity absolutely is the best option, and another slider experience where it isn't. I'd have to be out of my mind to include two slider libraries, so usually that means I just don't use Flickity.

I understand the original thinking behind "Flickity is a slider library, it shouldn't include other types of transitions", but this doesn't mesh with my thinking about these types of experiences, which is that they are collections of rotating content and the type of transition is just an implementation detail.

If you want a fade carousel, you don't need Flickity. You can build it mostly with CSS and some light JS.

Here's a short list of things Flickity provides that are separate from "flicking":

• Keyboard control
• Slide control UI
• Navigation for another flickity
• Disabling slideshow functionality at certain sizes using watchCss
• Grouping Cells
• Setting browser hash based on slide
• Automatically resizing based on content
• imagesLoaded support
• Fullscreen
• Full API for adding slides, removing slides, changing slide, getting current slide, etc.

Maybe most of those features in isolation aren't too big, but in aggregate that's a lot of functionality to get for free even if I have no interest in a flicking experience.

[gingersoulrecords]

Nice. Flickity does carouseling better than Slick/Owl/etc, and fading/dissolving is a more elegant transition style than sliding. If a design demands elegance and subtlety, it'd be nice to have the option instead of hacking (I currently hack).

I'd be willing to sacrifice draggability and all the grouping stuff (aka force a single, full-width slide for fading) for a fading carousel that actually responds to quick 'next' clicks.

[mkstix6]

A scenario:
On sites where we have designed a large, relaxed-fade-transition, hero-area on one page. But also sliding carousels of items on other pages (especially common in our mobile designs).

Rather than serving two libraries to achieve the two carousel types.
It would be great, performance wise, and developer convenience wise, to serve the flickity library only and use for both carousel types (without unofficially hacking it to achieve fade-transition).

Other comments:

• I haven't found a carousel that remotely beats flickity for all the reasons @cmalven listed. Plus the documentation is excellent. These things keep me coming back to flickity.
• Love the idea about the swipe gesture actively transitioning/controlling the opacity change. I don't think I've seen something like that out in the wild.

[jnicol]

A +1 for this feature. Flickity is my preferred carousel, and fade transitions are the one feature I miss. About half the carousels I implement require fade transitions, and although the CSS hack described earlier in this thread does the trick, I would prefer for this to be officially supported by Flickity.

[evadecker]

I'm also using Flickity and I'm hoping to achieve somewhere between a swipe and a fade.

Imagine the fadeout solution as posted above, but the prev/next slides are offset by about 10% in either direction, so the direction of swipe is still visible—similar to current implementation, but more subtle than moving 100%.

@desandro maybe retaining movement (but not full movement) would ease some of your hesitation to this feature? :)

[desandro]

🚨🚨 I've decided to build and maintain fade behavior for Flickity. 🚨🚨

Work on flickity-fade is currently under way. I hope to release the new package in the next couple weeks. Only took 4 years 😅

Thanks to everyone for displaying interest in this feature and for your patience waiting for its realization.

[o-l-e]

I understand wanting to keep Flickity as a pure swipe carousel, but i think this is a useful feature in some cases. I tend to use carousels with swipe for touch formats, and fade for mouse/keyboard based formats. It is more subtle and easier on the eyes on large screens with fade, with less movement. So it would be useful if this feature could be changed with media queries or touch detection somehow.

I really like Flickity, and as a previous comment points out, it would be nice to not have to use two sliders. Besides there are so many decent fade sliders out there, but few swipe sliders as good as Flickity, so fade would be a nice secondary feature.

Keep up the good work @desandro!

[CHEWX]

@o-l-e Look above your comment :)

[o-l-e]

@CHEWX i know, i was just commenting since it was announced as a fetaure :)

[gavin310]

@desandro This is awesome news! Thank you!

[intensr]

finally nehehe

[desandro]

You can now fade with Flickity v2.2.0. Add the flickity-fade to enable fade option. See Flickity fade docs. flickity-fade is an add-on package, so it needs to be installed separately. Fade works with dragging, groupCells, wrapAround, imagesLoaded, and (hopefully) everything else in the Flickity feature-set.

I'm closing this issue as resolved. If you do run into a bug with fade, please open a new issue here or in the flickity-fade Issue tracker

lol Four years +1 day since OP. Thanks for hanging tight 🐻🌈

[clarknelson]

Thanks for this! using on my next project

[pete-willard]

Legend!

[desandro]

Thanks for all the positive support. I'm now locking this thread as its a big one so we can all move on.

If you do run into a bug with fade, please open a new issue in the flickity-fade Issue tracker or on this main flickity tracker.