The TransitionEnd Event | kirupa.com

by kirupa | 4 January 2013

While a transition is something you would bucket squarely in the CSS category, there is a certain level of co-operation between it and JavaScript. Events is one area where this cooperation really shows itself.


This is a companion discussion topic for the original entry at http://www.kirupa.com/html5/the_transitionend_event.htm

Hi Kirupa!

Its me again, still battling along to get my flyout gallery system to work like I want it!

After trying all sorts of tricks, time delays and intermediate classList changes to my transitioning divs to try and make it work like I want it, entirely without success, I realised something very important! If a transition is triggered by a classList or other kind of class change, the code does not wait until the transition has completed before continuing to execute! If I make two classList changes to the same element in a row, the second one simply replaces the first one instantly and the first transition does not even get to begin. Doesn’t matter how many classList I chain one after the other, only the last one makes any difference!

If I put an alert() in the middle of the sequence, the one before the alert() executes and I see it run to its end. After clicking OK the sequence “jumps” to the final transition.

I have just discovered the solution while wading through your and other tutorials online. I need to use the “transitionend” event!!!

Well, the weekend is here and I shall be spending a chunk of it working through my code! With a bit of luck I will finally have my gallery working like I want it!

I have probably spend 50 hours on this obstacle so far! More news later! Looking forward to the more advanced tutorial on “transitionend” and multiple transitions that you mentioned in your first tutorial!

I didn’t realize that about the classList behavior. That is something I’ll fiddle with this weekend to see how to workaround that haha.

For the more advanced transitionend tutorial, you can find that here: https://www.kirupa.com/html5/animating_many_elements_using_transitions.htm

Excellent! Thanks. Thinking about it it’s actually obvious. If you “mouseout” while the transition is halfway done,the transition reverses automatically as you know. I think they achieve that by simply reinstating the original class state and removing the temp one caused by hovering or whatever. So it makes sense that if you change the attribute settings in other ways during a transition it instantly forgets where it was going to and begins the new one from there. Because the interpreter is so fast, if you triggered say 100 such transitions one after the other without a timeout or transitionend or something, the only one you actually get to see is the last one, although they would all actually start.

That’s my theory anyway!

1 Like

That is my theory as well :slight_smile:

Hi again Kirupa. Things are progressing apace my end. Gradually solving all my difficulties one by one.

My current quest is to build an image carousel that looks like a jquery / flash type of thing but only with HTML/CSS and a tiny tinge of javascript.

What I thought I would share with you (if you hadn’t worked it out already) is a little trick way to get around using settimeout. I am under the impression that, as javascript is single threaded, when there is a settimeout call waiting, everything else sits in the thread queue till its finished. One of the causes for jumpy javascript animations? I needed a different way to trigger time gaps.

Then I thought - what about using an invisible transition (can be an empty div) and a transitionend event so the javascript can carry on regardless doing other things? Like this you can have something wait seconds or minutes to fire without it interfering in your scripts.

A neat way to time the delays in my carousel!

For a responsive timer, you should look into requestAnimationFrame: https://www.kirupa.com/html5/animating_with_requestAnimationFrame.htm

It loops your code at your display’s refresh rate…around 60fps for most monitors. While looping a 0-second transition and listening for the transitionEnd event will work, I think the requestAnimationFrame approach may be better.

:slight_smile:

Hi Kirupa,

I’ll take a look at that! Thanks. In the meantime, check out my finished image carousel ready to incorporate into my website. Its really simple to add more images to it. And the anims are so smooth! As you promised! Buttery your word was!

http://www.smooth-operator.co.uk/BlockAnim_Builder.html

The delay duration, which I easily can make any length I want, is controlled by a div that moves invisibly across behind the scenes current setting 5s. So apart from a millisecond burst once each cycle, the javascript is not involved in the timing at all. And quite a small amount of code too!

Which reminds me - does your prefixfree js script deal with all the methods I have used here? Can I make them all just the plain versions?

Thanks!

Looking forward to hearing what you think!

Hmmm…seems this only runs in Firefox at the moment…looks like I need to put in some prefixes…or is it the DOMLoaded call that is failing me? I’ll test it with a button tomorrow…

You should use the plain versions from now on. Browser support for almost everything I talk about in that article is near universal :slight_smile:

One issue might be that the transition isn’t getting triggered. The reason is that different browsers react differently to when a transition needs to play. My suggestion would be to not use transitionend but instead use straight-up setInterval to periodically move to the next image.

You can see a version of that here: https://www.kirupa.com/snippets/examples/content_slider_automatic.htm (It’s part of this content slider tutorial: https://www.kirupa.com/html5/creating_a_sweet_content_slider.htm). There are much simpler ways of doing this, and I’ll do my best to carve out some time to fiddle with that. The current example tries to be very generic, and hence…unnecessarily complex.

Hi Mr K! I must say you are very good at getting back to your fans! Excellento!

I changed the original call to an “onload” in the body tag and it now works perfectly across all my PC browsers. Yay!

I took a look at your beautifully executed examples. I had actually been through these when planning my slider. I wanted to achieve a couple of extra things with mine. I wanted to be able to make mine cycle a large number of images easily without having to recode. But I didn’t want to have to load them all at startup. So my next image always loads during the wait time. All I need to do is set the total number of images and add files to the folder with the correctly numbered filenames. I could have made it automatically count the files like my Pics page code does, but its easy enough this way too.

My choice not to use setInterval or SetTimeout was so that the javascript part only runs for a microsecond each cycle and the rest was handled by the browser.

Now for the video player. As a nice bloke I know always says - onwards!!

Ah! That’s a great design. My examples totally won’t work, but I do have a partially finished variant that selective loads the next image. I’ll share it here once/if I finish it and see if turns out to be useful for you :stuck_out_tongue:

Btw, were you able to fix the cross-browser issue?

Hi Mr K!

As I mentioned above in between all the waffle - I fired the animation from the body tag with an “onload” (instead of the DOMloaded thing) which works on all the browsers I have installed.

1 Like

Hi Mr K!

Brief update - I have now used a transition event on my site as a pure timer. My backround images change every 7 seconds. While one image is displaying the next one is loading. The next image load is triggered by the “transitionend” of the cross fade. At the same time a transition based on a 3dTranslation is fired which simply moves an invisible div 400px in 7 seconds (totally abitrary - could have been any transition) at the end of which another “transitionend” event starts the process again. Works brilliantly and doesn’t need to wait for any javascript processes to complete. So the user can comfortably continue browsing the site.

I think this use of transitions tells us that a pure DOM timer would be a really good addition to html5/css. A sort of invisible stopwatch perhaps?

1 Like

I agree! We can definitely use better timers, and I really like your workaround of using a transition to play that role :slight_smile: