hasDisabledAnimation isn't `false` by default about collapsed HOT 3 CLOSED

I checked the lib code, and found the issue.
It's usePrefersReducedMotion -> window.matchMedia('(prefers-reduced-motion: reduce)')

I don't think there's any mention of this behavior in the documentation - I guess it's worth mentioning, otherwise it appears to be a 100% bug for a developer, especially when it used to work normally before. For me that is a double surprise, because I don't have any motion disabled in the browser specifically. It just turned out that I had that "reduced animations" setting set on the OS level (and I don't remember why or when, heh).

Also, I don't think that such a lib should cater for (prefers-reduced-motion: reduce) at all - that's not kind of motion that requires being reduced to complete none. That is my opinion though, I might be wrong as I don't physically suffer from animations per se, just don't like the ones explicitly long and vivid. But in this case - the adequate (!) animation is the core reason this lib is used in the first place.

from collapsed.

One of the goals of this project is to be 100% accessible out of the box, not just providing the animation. In that case, the component is now working correctly--if the user enables the setting for preferring reduced motion, the collapse should observe that preference.

I think most browsers derive their own motion preferences from the OS preferences (I know this is the case for most browsers on MacOS). You might be able to override this for your browser in the browser settings.

I do see your perspective, though, and I did wonder about the necessity for adding it. Hopefully it works for you to manually override the setting in your implementation.

Thanks for the PR!

from collapsed.

@roginfarrer I've added #150 to complete the missing part.

from collapsed.