Martinomagnifico / reveal.js-appearance

An animation plugin for Reveal.js that animates elements sequentially like in Powerpoint. Perfect for online portfolios or other presentations with images.
https://martinomagnifico.github.io/reveal.js-appearance/demo/demo.html
MIT License
99 stars 12 forks source link

The 'autoelements' setting breaks the fragment images #14

Closed libralibra closed 4 weeks ago

libralibra commented 1 month ago

After you've fixed the bug of fragments appearing on every slide in pdf-print, another bug appeared (It was not there before this fix if I remember correctly). Would you please have a look? Thanks a lot!

Bug description

  1. set 'autoelements' for 'img' in setting as:

    autoelements: {
    'img': 'animate__fadeIn'
    }
  2. use 'fragment' with images in one slide as:

    
    <section>
    <!-- if I add 'fade-out' to img1.png, it won't appear at all -->
    <img src='img1.png' class='fragment'>
    <img src='img2.png' class='fragment fade-in'>
    </section>```
  3. expected result: img1 appears first, then img2

  4. buggy result: img2 does appear, but changes back to img1 afterwards

  5. why is it a bug in appearance? After turning off the 'autoelements' for 'img' tag, it behaves properly.

Screencasts that demonstrate the bug

  1. the correct fragment animation correct

  2. the bug after turning on 'img' in 'autoelements' setting, I played the slide twice. bug_played_2_times

libralibra commented 1 month ago

I've no idea why the gifs cannot be inserted in the post after editing. crazy github, but you can view the two files using the URLs directly.

correct one: https://github.com/user-attachments/assets/ff613e39-5158-4448-9a45-5d715d86e37a

bug one (played 2 times): https://github.com/user-attachments/assets/52e80a2a-b431-4a3f-80cc-87e1ec7af6a2

Martinomagnifico commented 1 month ago

Will check this out. Busy times, hold on.

Martinomagnifico commented 1 month ago

It is not an 'autoelements' issue, but can be seen by manually adding classes as well. It is also not a new issue, and also not really an issue:

The issue here is that the fragment gets that "fade-out" class. A fragment with that class starts as being visible, then fade out as that fragment gets triggered. However, adding an Appearance class as well to that element will use the fragment trigger to let it appear (not disappear/fade-out), so it will have the pre-triggered state not visible .

In short: Appearance elements animate into visible either after a slide change, or if is a fragment, at the fragment trigger. Before that, they will not be visible). Fragments with a fade-on class behave in the exact opposite way.

So elements that are a fragment AND have both an appearance AND fade-out class will be invisible before and after the fragment trigger. That is the logical result of mixing the classes.

Even though it is expected behaviour, I could change the documentation to make it clear that while elements can be both fragments and have an Appearance class, that will only work for regular fragments (not fragments using fade-out or in-out). Would that work?

In the mean while, to achieve a desired effect, you can nest Appearance elements inside fragments.

libralibra commented 4 weeks ago

It is not an 'autoelements' issue, but can be seen by manually adding classes as well. It is also not a new issue, and also not really an issue:

The issue here is that the fragment gets that "fade-out" class. A fragment with that class starts as being visible, then fade out as that fragment gets triggered. However, adding an Appearance class as well to that element will use the fragment trigger to let it appear (not disappear/fade-out), so it will have the pre-triggered state not visible .

In short: Appearance elements animate into visible either after a slide change, or if is a fragment, at the fragment trigger. Before that, they will not be visible). Fragments with a fade-on class behave in the exact opposite way.

So elements that are a fragment AND have both an appearance AND fade-out class will be invisible before and after the fragment trigger. That is the logical result of mixing the classes.

Even though it is expected behaviour, I could change the documentation to make it clear that while elements can be both fragments and have an Appearance class, that will only work for regular fragments (not fragments using fade-out or in-out). Would that work?

In the mean while, to achieve a desired effect, you can nest Appearance elements inside fragments.

Great explanation of the deeper root of the issue. Thank you very much!