You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You’ve caught the biggest change to ScrollReveal since its release @MoradHamdy!
The simplicity and ease of the data-sr API is what many have come to love about ScrollReveal, which is what made it such a difficult choice to remove.
Some products are meant to be outgrown, but one of my goals is for ScrollReveal to grow with the industry and the developers that use it. This also means I need to take a hard look at things to remove as it grows, to keep things simple and focused.
When I developed the 3.0 release candidate, I supported both the data-sr API and the new JavaScript API—but it wasn’t until I began writing the documentation that I really noticed the confusion of having both strategies.
It’s a bold and critically breaking change, but the JavaScript API truly is a cleaner and more flexible strategy. I’ll admit it's a little less beginner friendly, but I think it's simple and documented well enough to help those beginners grow—after all, inline styles are easy too… but writing and maintaining clean stylesheets is accepted as a better practice, and I think 3.0 follows suit.
I welcome your feedback, especially on how I might help users longtime users who are looking at 3.0 and asking this same question. 🙇
Thanks for the info. I decided to keep my data-sr attributes (without any value though) since I usually use data attributes when working with selectors instead of classes.
Hi there,
I don't know if the approach of using "data-sr" data attribute with HTML elements is still supported or not such as this:
data-sr="enter top move 40px over 0.4s wait 0.2s"
The text was updated successfully, but these errors were encountered: