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.
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!
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.
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.
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.
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!
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?
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
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.
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
Btw, were you able to fix the cross-browser issue?
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.
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?