Skip to content
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

Closed
ezadoo opened this issue Apr 30, 2020 · 5 comments
Closed

Comments

@ezadoo
Copy link

ezadoo commented Apr 30, 2020

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:

  1. 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.

  2. 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.

@mciastek
Copy link
Owner

mciastek commented May 21, 2020

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.

@tobimori
Copy link

tobimori commented May 21, 2020

Maybe we can use the <noscript> Tag and then apply inline styles which makes the elements visible?

@mciastek
Copy link
Owner

Maybe we can use the <noscript> Tag and then apply inline styles which makes the elements visible?

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>

@tobimori
Copy link

That works well! Thanks!

@mciastek
Copy link
Owner

Closing with 212402e

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants