Good on them for listening to prefers-reduced-motion [1]. To the folks complaining about motion, consider configuring your operating system to reduce motion -- make your user agent work for you!
In addition, "reduced motion" is only a partial solution to the problem of unwanted motion. I would much prefer zero motion. In Firefox, it is possible to disable CSS animations globally, by adding the following to both chrome/userContent.css (with the appropriate namespace header) and chrome/userChrome.css in your profile directory:
This also requires setting toolkit.legacyUserProfileCustomizations.stylesheets to true in about:config
I have been disabling animation in userContent.css (which affects websites) for years with no problems. More recently, I realized I could also disable it in userChrome.css (which affects the Firefox UI). This exposes what appears to be a race condition bug involving tabs. Occasionally, a tab's close button will stop responding, and that tab will also become impossible to drag to new positions. This can be worked around by attempting to drag a different tab, releasing that drag, then immediately dragging the frozen tab to an empty part of the tab bar, which will unfreeze the tab.
I consider this minor annoyance well worth the benefits, which includes disabling animations that would be permitted with prefers-reduced-motion, such as the sliding of the "Find in Page" panel. It is possible that setting an extremely brief animation might avoid the bug without showing visible animation but I have not tested this.
From what I understand of the accessibility issue, reduced motion is about reducing motion, so I don't think that making the motion faster/more visually intense would help those who need the reduced option.
I think this is a different thing from people who just want things to feel faster/snappier, vs those who have an accessibility need.
I really like disabling animations on my phone. Everything is so fast, it's amazing. Reminds me that hardware has improved the the past decade.
Particularly with Android 12, wow. So many animations added, and they run so, so, so slowly. There were a number of rather severe UI glitches for the first few patches, but it's alright nowadays. Beyond 12's other major issues, that is - I highly recommend not upgrading. Maybe 13 will actually fix some of it.
I did that a week ago, just stumbled across the option in the accessibility options. Now I wish I had done it many years ago (is it a new option?). There's not a single animation that is better than its own absence.
The worst thing is that it isn't respected by many apps and browsers.
Yeah, generally speaking many things with "momentum" from a touch will still have momentum (probably a good thing) and anything doing custom animation code will be unaffected (not a good thing! use the framework please, app programmers!).
But it does at least get rid of that awful stretch-bounce animation on scroll views basically everywhere. That alone is practically worth it.
A little bit about how it works (from their docs)[0]:
> AutoAnimate is fundamentally a single function — autoAnimate — that accepts a parent element. Automatic animations will be applied to the parent element and its immediate children. Animations are specifically triggered when one of three events occurs:
The non-animated version is horrible though. I have a hard time seeing what's happening even when re-ordering just one item so when would speedrunning it ever be useful? I think it's a good example where the trade-off between feedback and speed makes sense.
What kind of real world situation do you imagine mindlessly blasting an add button as quickly as possible? The animation seriously improves the users understanding of what is happening. Throwing that out to support millisecond speed button blasting is bad UX
In examples, when adding an item to the list, I see a brief flash of the target state, then it goes back to the previous state and then an animation happens (mobile safari).
Is there a way for the library to eliminate this “blink”? Or is this behavior unavoidable with current one liner approach?
This is possible to fix but probably not by using Resize/MutationObservers (as the library does)
In Framer Motion we use React's layout effect to trigger the <motion.div layout /> animations (which are equivalent to this). The layout effect runs synchronously after DOM mutation and works cross-browser.
I’ve seen this on my own device (author of the docs site here) but after a force quit and restart of safari was not able to reproduce.
Would you mind if I asked a few questions?
- does your device have remote debugging enabled on Safari?
- was your phone in low-power mode?
- did you first access the site through a WebKit in-app browser panel before opening it Safari?
- what version of iOS?
- what model of iPhone?
Those are my leading theories for what contributes to the flash happening. If you force quit and restart safari and / or reboot your phone does it work as expected?
> - does your device have remote debugging enabled on Safari?
Do you mean “Web Inspector”? Yes.
> - was your phone in low-power mode?
No.
> - did you first access the site through a WebKit in-app browser panel before opening it Safari?
No.
> - what version of iOS?
15.2
> - what model of iPhone?
13 Pro Max
I did force quit Safari and I no longer see the brief flash of target state when adding items to lists. But I didn’t check if I saw that immediately before doing force quit, sorry. I’ll write if I ever see that again.
I just tried it in a different browser, firefox focus (also ios) and got the blinking; it was slightly different, there seems to be some other issue there too. BUT after force quitting ff focus, the issue is again gone.
I didn't look into the source code, but I wonder how it handles animations when an element moves in the DOM? How does it know that if I remove and add a new element, that it is in fact the same element that has moved? Probably need to have a unique id attribute?
things work great on 2000$ workstations and laptops, with low to no network latency, in a demo unburdened by the rest of garbage on the website
on a 8 year old device, with 200ms network latency, while the browser performs three hundred TLS handshakes with all the ads and tracking services... not so great
Page transitions on the web are just horrible. There is a reason that most websites these days are going for side sheets and pop up modals while apps still show real full pages.
Apps animate between making it look less janky and they also hold your position when you return while a web app will reload the whole thing including requests when you move back, losing your state and position.
With that in mind, it seems pretty nice if a library can make simple animations much easier.
The demo shows some promising examples that tend to be common polish on, say, iOS. The simple sorting/delete ListView example is pretty nice compared to the instant changes with zero feedback it's compared to.
Meanwhile, web animations by hand can take quite a bit of thought even for basic things, like fiddling with CSS `transition` and ensuring your component lifecycle sees it through. Always ends up being a bit brittle, like having to duplicate CSS time durations with your JS components.
The first example on the page is actually decent I think, visually showing the two elements swapping so you see where they moved to, but making it so automatic is going to be an irresistible temptation for many people.
Please don't. Animations should be added where they actually help the user, if you just animate everything you'll just make the user experience slower.
The first thing I do when using a new app or operating system is to disable all animations. I even wrote a Firefox extension just to disable the "smooth seek" of the code search tool OpenGrok because it slows me down so much. I hate animations on user interfaces with a passion.
Imo animations are an accessibility feature for people who can't follow UI updates very quickly and who need the smooth transitions to keep track of what's on the page where. They should be opt-in like high contrast themes.
Maybe spend a minute looking at what the thing does instead of posting a knee-jerk comment based on the title or some tag line. This library animates immediate child addition/removal/movement of elements you attach it to, not “everything”.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
https://news.ycombinator.com/item?id=30237846
In addition, "reduced motion" is only a partial solution to the problem of unwanted motion. I would much prefer zero motion. In Firefox, it is possible to disable CSS animations globally, by adding the following to both chrome/userContent.css (with the appropriate namespace header) and chrome/userChrome.css in your profile directory:
This also requires setting toolkit.legacyUserProfileCustomizations.stylesheets to true in about:configI have been disabling animation in userContent.css (which affects websites) for years with no problems. More recently, I realized I could also disable it in userChrome.css (which affects the Firefox UI). This exposes what appears to be a race condition bug involving tabs. Occasionally, a tab's close button will stop responding, and that tab will also become impossible to drag to new positions. This can be worked around by attempting to drag a different tab, releasing that drag, then immediately dragging the frozen tab to an empty part of the tab bar, which will unfreeze the tab.
I consider this minor annoyance well worth the benefits, which includes disabling animations that would be permitted with prefers-reduced-motion, such as the sliding of the "Find in Page" panel. It is possible that setting an extremely brief animation might avoid the bug without showing visible animation but I have not tested this.
I think this is a different thing from people who just want things to feel faster/snappier, vs those who have an accessibility need.
Particularly with Android 12, wow. So many animations added, and they run so, so, so slowly. There were a number of rather severe UI glitches for the first few patches, but it's alright nowadays. Beyond 12's other major issues, that is - I highly recommend not upgrading. Maybe 13 will actually fix some of it.
The worst thing is that it isn't respected by many apps and browsers.
But it does at least get rid of that awful stretch-bounce animation on scroll views basically everywhere. That alone is practically worth it.
(If anyone is looking for the option: it's in the developer settings and there are two entries, one for windows and another for general animations.)
> AutoAnimate is fundamentally a single function — autoAnimate — that accepts a parent element. Automatic animations will be applied to the parent element and its immediate children. Animations are specifically triggered when one of three events occurs:
> A child is added in the DOM.
> A child is removed in the DOM.
> A child is moved in the DOM.
[0]: https://auto-animate.formkit.com/
In the animated one, I have to wait for the animation to finish.
Seems like a poor example of when animation adds value.
But there are places it works.
Is there a way for the library to eliminate this “blink”? Or is this behavior unavoidable with current one liner approach?
https://codesandbox.io/s/framer-motion-reorder-animation-bvi...
I don't trust the implementation of observers, usually in Safari, to reliably recreate this effect. I'm not sure it's even specced.
Would you mind if I asked a few questions?
- does your device have remote debugging enabled on Safari?
- was your phone in low-power mode?
- did you first access the site through a WebKit in-app browser panel before opening it Safari?
- what version of iOS?
- what model of iPhone?
Those are my leading theories for what contributes to the flash happening. If you force quit and restart safari and / or reboot your phone does it work as expected?
Do you mean “Web Inspector”? Yes.
> - was your phone in low-power mode?
No.
> - did you first access the site through a WebKit in-app browser panel before opening it Safari?
No.
> - what version of iOS?
15.2
> - what model of iPhone?
13 Pro Max
I did force quit Safari and I no longer see the brief flash of target state when adding items to lists. But I didn’t check if I saw that immediately before doing force quit, sorry. I’ll write if I ever see that again.
https://github.com/metafizzy/isotope
It was so popular back in the day but hasn't received any recent updates.
1) it adds meaningful value to the ux (like that sorting example in the link)
2) it’s a micro interaction, like a heart lighting up when you like something, so it adds delight to the ux and I don’t have to wait for it to finish
3) it covers up other jank in the ux, like known slow processing or something
If you insist of animations, make them incredibly fast, otherwise we’re all going to be mad eventually.
It’s ALWAYS better to invest the time you’d have spent on animating shit to instead just make your app faster
I think just a layer of smoothness can help a lot.
I’d argue that the web is almost always janky, no matter how fast or slow.
on a 8 year old device, with 200ms network latency, while the browser performs three hundred TLS handshakes with all the ads and tracking services... not so great
Apps animate between making it look less janky and they also hold your position when you return while a web app will reload the whole thing including requests when you move back, losing your state and position.
With that in mind, it seems pretty nice if a library can make simple animations much easier.
The demo shows some promising examples that tend to be common polish on, say, iOS. The simple sorting/delete ListView example is pretty nice compared to the instant changes with zero feedback it's compared to.
Meanwhile, web animations by hand can take quite a bit of thought even for basic things, like fiddling with CSS `transition` and ensuring your component lifecycle sees it through. Always ends up being a bit brittle, like having to duplicate CSS time durations with your JS components.
I'll have to play with it.
Imo animations are an accessibility feature for people who can't follow UI updates very quickly and who need the smooth transitions to keep track of what's on the page where. They should be opt-in like high contrast themes.
Blink does not work :(