Hacker News Reader

Comment by tgsovlerkhgsel | Hacker News Reader

It's almost impossible to reliably distinguish animations required for a web site to work properly from animations and changes that can and should be disabled.

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.

View on HN

I disagree completely. When implemented by the browser itself, it's straightforward to ensure all the relevant events are still fired without presenting the actual animation to the user. As for the list you brought up, a loading spinner spinning and the like is exactly what should be disabled. These are not interactions that are necessary for the site to function and they bring harm to some users.

If it moves spontaneously, it's unnecessary animation.

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

How does that address "Information you're waiting for being loaded once some process completes"?

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?

What it would likely mean is that animations would get stuck in their starting state so you'd see no content. And no one would bother fixing it for the 0.001% of users who turned this setting on so customer support would advise you to turn animations back on.

If web developers would use the actual browser APIs instead of hacking around everything (manually setting the position of items at every frame cool cool cool), this setting would be respected.

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.

Spinners are a total antipattern. If loading is interrupted by an error, the spinner just keeps spinning. And there's no need to display progress every millisecond, 0.1 Hz should be enough.

> If loading is interrupted by an error, the spinner just keeps spinning.

Only if written incompetently.

Or if you disable javascript the spinner remains despite the content being complete under it. Fucking web devs!

How about just drop most of the frames? Let them animate and show users how it’s going every once in a while

My principle mobile driver is an e-ink device.

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.

>that the next ad mascot will be written in JavaScript

The horror....

This would mean a) it will still animate regardless of setting b) there's a high chance it will spike your CPU load because your CPU cycles don't cost the authors of the ad money.

It has tangential costs, because a site which is slow or drains battery will lose at least some users or SERP positions and a site owner will take measures to rebalance that. All this already works through various metrics.

Haven't seen that work in practice...

> that the next ad mascot will be written in JavaScript

That's quite literally true already: https://nextjs.org/conf

Reply on news.ycombinator.com