Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature / frontend] Change animated emojis to always be static until hovered over/tapped on in the web interface (no JS involved & still respects prefers reduced motion) #3474

Open
jwbjnwolf opened this issue Oct 21, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@jwbjnwolf
Copy link

jwbjnwolf commented Oct 21, 2024

Is your feature request related to a problem ?

You have animated emojis disabled in your fedi client so you do not get hurt by flashing & fast paced animated emojis used in the toots and display names you scroll by.

Issue that always crops up when you have them disabled though is the possibility of not realising there are such emojis when you interact, which is a reason back on Masto I refused to turn off the animated emojis because I didn't want to risk boosting them unaware. But now I don't hugely boost, and simply don't want to deal with the discomfort for the sake of avoiding discomforting others anymore who may be on software/clients that doesn't even have the ability to disable them.

GtS has by default emojis animated when looking at posts in the web interface, compared to Masto's default behaviour of not having them animate until you hover/tap on the post containing them (and if I can remember Masto v3.X's legacy static public interface it was based on individual emoji vs the message containing them as a whole that Masto v4.X is like.).

v0.17.0 of GtS brought in the huge improvement of adding prefers-less-motion support to them and gifs etc. But then I don't particularly fancy myself enabling reduced motion on my devices (found in accessibility options on macOS, Windows, iOS and Android), plus I never even knew about that option until the changes to support it by GtS.. and I'd simply like to have static emojis on my own instance that only animate when hovered/tapped on for all viewers.


Describe the solution you'd like.

Well the solution I've done on my own fork is this commit.

I've duplicated in the emojify.go the original image source in the picture element, adding to the class name for the one pointing to the original emoji files as emoji original and then the duplicated one as emoji static, with the url in the src being swapped to staticURL.

Then in CSS, which I've just added to my custom.css have this CSS:

.emoji.original { display: none }
picture:hover .emoji.static { display: none }
picture:hover .emoji.original { display: inline-block }

This hides by default the original versions by default, only showing static, then on hover over on the picture element of said emoji, it will switch the display around on the original and hiding the static. This doesn't mess with prefers-reduced-motion being respected, that behaviour still happens as designed that when reduced-motion is enabled, static emojis will still not animate when hovered over.


Describe alternatives you've considered.

Again, could have reduced motion on your devices but then that only is well for you and you have to do that for all devices.. Or if you don't want to do the CSS too and have emojis just always be static, then no need to duplicate the emoji source, just swap the url to staticURL, build the binary and job done. Though having emojis animate on hover is extremely nice behaviour so whilst a flashing emoji or so isn't going to suddenly hurt me upon loading the thread containing such, I'll notice oh that an animated emoji when hovering and be well aware of it before I maybe click through onto the remote instance where don't have control over it animating upon load and it then causing a lot of discomfort.


Additional context.

This way of swapping the static and original emojis via CSS does have the caveat that the emojis when being swapped on hover at first need a brief bit of time to load so you'll notice it on a slower connection, though at the same time that's somewhat a feature rather than a bug since it means not loading the duplicated emojis if you don't plan on hovering over them. This also does regardless if the original is animated or not, would need something behind the scenes probably to only do that for ones where the original is infact animated.. but this is a simple quick trick solution exactly for the behaviour I wanted on my instance.

Not making this issue as in for being integrated into GtS, rather for searchability for anyone else looking in issues about this to have their emojis behave like this that they don't automatically animate again until hovered over. Though a toggle in the settings definitely would be extremely welcome (since even the worst fedi software for photo-sensitive users .. Misskey .. has the ability to disable them animating by default from what I'm aware).

Same could be done for the profile pictures and covers, though chosen to just do for emojis as it's much more likely to run into animated flashing/fast paced emojis than it is flashing/fast paced animated profile/header images.

Here's an example of the behaviour from my instance.
(Hover over that cute lil sloth, give them a pat for the good lil sloth they are!).

And here's a recording of it.. Note that suspicious pink foxxo I'm avoiding hovering over.. it's a flashing one, hence why I reallty wanted to have this behaviour. That clip is firstly on desktop and then on android.

Big thanks to adding the prefers-less-motion support in v0.17.0 with the addition of the staticURL so that this is even able to be done which cannot be done on versions prior.

@jwbjnwolf jwbjnwolf added the enhancement New feature or request label Oct 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant