Reduced-Motion: Replace animation: unset and transition: none with 0-length durations.

[shpuld]

This way motion is still reduced and functionality that depends on animations/transitions doesn't break.

[toviszsolt]

Please don't do that!

Related issues: #932 #934 #928

Solution:

@media (print), (prefers-reduced-motion: reduce) {
  .animated {
    animation: unset !important;
    transition: none !important;
  }
}

[shpuld]

@sivot that's not a full fix, setting animations to unset/none with !important can still break websites for those with animations disabled with no good way of overriding it. That's an unacceptable solution if you ask me.

[opallehmann]

K

[toviszsolt]

It's okay, if that break the animations in only cases below:

• On OSX or IOS reduced motion option turned ON in OS level
• On Windows Show animations in Windows turned OFF in OS level

In any other cases the animations need to work...

Testing:

• OSX: Settings > General > Accessibility > Reduce Motion
• IOS: System Preferences > Accessibility > Display > Reduce Motion
• Windows: Settings > Ease of Access > Show animations in Windows (the new
  Chrome and Firefox update watching this option and this is why prefers-reduced-motion: reduce needed )

[shpuld]

You don't get the issue here, the issue is not that animations don't do their thing doing their thing, that's exactly what we expect, which is what 0-duration animations do as well. The problem is that setting animations/transitions to unset/none can break functionality of websites, and not just the appearance of animations, this is not acceptable. We don't want people with animations disabled to not be able to use the site because a library has been careless.

For example (a real example) you could have a sliding menu, and its visibility is done purely with animations, with duration 0, toggling the menu will just make it just appear/disappear instantly without an animation, with animations completely removed with unset/none, the menu will forever be at open/closed state depending on how it's made, and therefore actually broken.

[toviszsolt]

@shpuld right. Sorry. ;)

[eltonmesquita]

This seems a solid solution and will get merged. I'll do this as soon as I have a little more free time as this will need a new release.
Thanks!

[toviszsolt]

@shpuld I think there will be a little trouble with infinite animations... I suggest to extend the block with this: animation-iteration-count: 1

Otherwise the solution tested, it works fine. Good job.

[shpuld]

Hmm, I hadn't thought about that, gotta investigate and try it out I suppose

[toviszsolt]

@shpuld On IOS animation js events (like animationend) don't fire with 0s durations. I suggest to change duration times from 0s to 1ms. I've tested 1ms durations and it works on IOS, Windows and Android so.

[shpuld]

Thanks @sivot , I'll do that!

[toviszsolt]

Tested, works fine.

[shpuld]

any update @eltonmesquita ? would be nice to get this upstream

[eltonmesquita]

Sorry for the long delay, but I was on a tight schedule. Anyway, I had to do my research to be sure what was the best solution. As @sivot noted the current PR is indeed the best case scenario, although it feels a bit hacky.

I'll merge it and release the new version. Thanks for the PR @shpuld .

[MrCaffe]

It's okay, if that break the animations in only cases below:

• On OSX or IOS reduced motion option turned ON in OS level
• On Windows Show animations in Windows turned OFF in OS level

In any other cases the animations need to work...

Testing:

• OSX: Settings > General > Accessibility > Reduce Motion
• IOS: System Preferences > Accessibility > Display > Reduce Motion
• Windows: Settings > Ease of Access > Show animations in Windows (the new
  Chrome and Firefox update watching this option and this is why prefers-reduced-motion: reduce needed )

Thanks a lot, it fixed my problems with animations not loading at all in any browser. Apparently when I formated my Pc I turned off everything in W10.