New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fallback for no-js or feature detection / activation class for Sal.js #52
Comments
This one is a bit complicated, because adding such class will cause flash of content when sal is initialised. Imagine, that at the beginning we show all animated elements. Then when sal is launched, we hide them. So user with working JS for split of a second will see animated content. I'm not sure if I'd like to introduce such change to library, that will cause in most of the cases flash of animated content. I think it should be handled by developers themselves. But, I'd appreciate any idea how to handle this case without introducing flash of animated content. |
Maybe we can use the |
That's a great idea! Honestly, it can't be a feature of this library, but I can make it as a recipe and put it into docs, so anyone can use it later. I think that something like this should work: <noscript>
<style type="text/css">
[data-sal|='fade'] {
opacity: 1;
}
[data-sal|='slide'],
[data-sal|='zoom'] {
opacity: 1;
transform: none;
}
[data-sal|='flip'] {
transform: none;
}
</style>
</noscript> |
That works well! Thanks! |
Closing with 212402e |
When testing different scenarios on my website I noticed if JavaScript is disabled or sal.js couldn't be loaded for some reason, the animated elements are staying invisible.
On my sites I’m usually detecting disabled js with removing a „no-js“ class from the html tag and loading a different css-file. But this doesn’t solve the problem if js is enabled but Sal.js couldn’t be loaded, so I think it would be a simple and effective but really useful feature for sal.js to have a „native“ way for creating a fallback.
I’m not sure what the best practice would be for sal of the following two simple ways:
having a specific class on the html element which is removed if sal is loaded. So there only a class must be added in manually/not by sal.js, which has the advantage that the according css is smaller as the additional class is only needed for the fallback-part and no additional class has to be included when creating additional/custom animations.
adding a sal.js specific (Like „sal-enabled“) class to the html or body element, like most js librarys do. The advantage would be that no “manual“/separate js work has to be done, as sal handles this by its own and there is done nothing if it couldn’t be loaded. Disadvantage is that the sal-activated class has to be included in all css selectors which makes the the css file a bit larger (not much larger than version 1 when using gzip) and as written above the class has to be included in all custom animations.
I personally prefer the second way, which I’m currently integrating in my project, as my compiled css is already has already around 15k lines of code and I’m not done yet, so i don’t mind the bit additional code I don’t have to care about adding the class on the html element.
The text was updated successfully, but these errors were encountered: