Closed letoast closed 3 years ago
Good idea, I’ll look into it.
Can you explain when you use this? Auto-animate will change properties of elements that are the same across 2 slides, but then making the (second) item invisible at the start of the second slide by adding an appearance class to it does not make sense to me.
Sorry, I don't understand this part:
making the (second) item invisible at the start of the second slide by adding an appearance class
The use case is pretty simple. I have at least one element that is being animated across multiple slides and I'm also using reveal.js-appearance to simplify the transition of other elements on their respective slides. This results in the elements that 'persist' across multiple slides being animated first and then all of the other elements.
What I would propose and I think it also makes sense, is to have the option of other elements that aren't auto animated to start transitioning with other auto animated elements. This is an option in PowerPoint as well, none-the-less.
Ah yes, I think this is a good middle path solution!
On Mon, Jun 21, 2021 at 10:41 PM Martino @.***> wrote:
I think we could also use the ‘autoanimate’ event. This will only fire at the start of any (second) slide with the data-auto-animate attribute.
It is extremely unlikely that users want a pause when using auto-animate. So instead of setting it in the options, we just start it directly after any autoanimate event.
How about that?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Martinomagnifico/reveal.js-appearance/issues/5#issuecomment-865329981, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6GF46XR52HT2P77QJJA7LTT6PV7ANCNFSM47CEHJRQ .
Yeah I removed that comment because I did not get the use-case yet. Now it makes sense, because the elements are not the ones being auto-animated. They should just start at the same time.
It might just be that it could be a per-slide setting, by using another data-attribute. What do you think of that? I can imagine slide transitions where the user does want a delay.
Hm probably both would be a good option, like some of the other default Reveal.js options(transition type in config vs transition type per slide). For example in my current project I have about 30 slides and probably half or more have auto animated elements(it's a more graphically intense presentation).
I’ll have a new release either this weekend or the next.
Keep in mind that Reveal transforms opacity for all non-autoanimate items, while Appearance does the same on most of the effects. To avoid strange behaviour, wrap your Appearance items in a parent. For example, a list of animated bullet points works well, because the animated class is on the children, not the parent. Separate headings or other elements do not have that, so should be wrapped.
Excellent news! Will update my layouts according to your suggestions.
Published, check it out
Hey Martin, the appearevent: 'slidechanged' appears to work as expected, but the appearevent: 'auto' doesn't. Either there is something wrong with my setup or there's a bug. I'll have to investigate later and try to reproduce it on codepen. The elements animations don't fire at all, they don't even start animating.
It seems the options do not get overwritten (to autoanimate) when using auto, you can set the appearevent to 'autoanimate', that should work for now.
Pushed a bugfix, let me know if I can close the issue. Also, I'm curious to what people can create using Appearance. Could you showcase it? (via email is fine too)
Right now the slides start animating when the transition has ended, leaving you with a pause between animations if you use auto animate. It would be nice to have an option to start animating on 'slidechanged' as well.