For example, try to distinguish (from "definitely should be blocked" to "definitely can't be blocked without breaking things"):
- An ad mascot hopping up or down telling you to click it
- A loading spinner spinning
- A progress bar
- Information you're waiting for being loaded once some process completes
You could disable all CSS animations and GIFs, but that will kill the loading spinner and risks that the next ad mascot will be written in JavaScript. And it will still not stop one of the biggest offenders in terms of blinking, ads that are being replaced by a new ad every 30 seconds.
See how it works in the Android world: anything that uses Animation, AnimationSet, ObjectAnimator, Compose animations, etc, all respect the system setting of animation speed (from 0 to 3x). As a developer, as long as you use the proper API, it'll work.
So, no, your ad mascot should be written with those APIs, and not using them should bring a massive performance cost that makes you think for a second or two about whether you're doing it right.
The horror....
That's quite literally true already: https://nextjs.org/conf
It is necessary for things to move only if:
- they are objects being dragged by the mouse (or finger in the case of touch input).
- they are the content of an animated image or video being played. (User preference needed there: auto-play or not.)
Do you want to delay the entire page until absolutely everything is loaded?
Maybe you want some clever code checking that you only go from blank to filled, and you'd better have the size ready up-front?
Only if written incompetently.
Whilst it's possible to support animation (and in fact does support video playback, at greatly-reduced image quality), at the higher-quality display modes most appropriate for text, all animation at < 1--2 s framerate, and virtually all animation outside actual paginated navigation (scrolling is possible, but ... unpleasant), really should die.
The prevalence of animations and video on the present web (the device supports web browsing, it's an Android tablet with an e-ink display) makes for an exceedingly unpleasant experience.
1. Maybe in 100 years, when we have powerful AI that and reliably identify problematic animation.
Unfortunately, Duolingo ignores this flag for many animations, and more than half of the screens are still animated.
I find the animations Duolingo uses to be obnoxious distractions, and I want them to be actually disabled when I tell it this. I also want this kind of thing to be switchable on a per-app level, so that I have a way to override the (I assume) opinion of the art department or the marketing person that thinks these animations are engaging or fun without having to also disable the non-obnoxious animations my other apps have.
(Mind you, at this point I'm thinking Duolingo has been a lost cause for the last few years; although the courses seem to still be improving, the UX has been getting worse faster).
(eg. to confirm an unconfirmed item, you tap on a coloured bar which then swoops a new pane from the right, shifts it up, zooms the map, and occasionally does a little blink refresh of the map. And you frequently get 4-5 of these a day, each one doing its little UI dance. God help you if you need to convert 10+ mis-identified transport segments to a single bus...)
Turned it on to make phone/ui fast and instant, found out it just doesn’t. Idk what people with vision problems need, but personally I need animations (either fade or motion) to not exceed ~100ms.
A better option is to respect the user, and if your site really can't run without animation, then just show an error stating that...Which shouldn't be a problem considering how many websites refuse to work just because you are using a chromium alternative that is realistically supported but just isnt Chrome itself.