Open igalic opened 6 years ago
🤦♂️
(From Linux 20 years in the future)
We shouldn't be adjusting fonts that will override the user's default emoji choice anyways. It's 2021 and we are detecting support based on having Linux but not Android in your user agent string 😅
I created a userscript to fix this on GitHub. I would be happy to accept patches for other sites, if any, that are using this component. https://userscripts.kevincox.ca/github-emoji-linux.user.js
same issue,fallback images are too ugly.
This is bugging me so much! @keithamus tried to fix this with #26, and the PR was rejected because it was uncertain how many users would be affected. I like @igalic's idea of suppressing this behavior for clients with Noto Color Emoji
installed, would that be possible?
We're unable to detect what fonts are installed. Perhaps one thing we could do is allow emojis for those with emoji explicitly listed in their UA, giving users at least some kind of workaround to enable emoji support:
-Mozilla/5.0 (X11; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0"
+Mozilla/5.0 (X11; Linux x86_64; emoji; rv:92.0) Gecko/20100101 Firefox/92.0"
Since 2016, Firefox includes its own font to support emojis, so there is no problem if the operating system does not support emojis.
6ba139
: Font added in 2016.1358240
: Start using Twemoji instead of EmojiOne.I don't know about other browsers, but at least in Firefox the check allow using actual emojis, instead of the image fallbacks.
I'm using Linux and have a custom emoji Library, it's labeled as Segoe UI Emoji
so most sites even Github can use it, I can see my custom emoji working for 500 miliseconds then this script overrides it by a fallback image like:
<img class="emoji" alt="+1" height="20" width="20" src="https://github.githubassets.com/images/icons/emoji/unicode/1f44d.png">
I realized that the cause for that probably is this snippet which consider Linux hasn't support for emojis? :thinking:
const onLinux = /\bLinux\b/.test(navigator.userAgent) && !/\bAndroid\b/.test(navigator.userAgent)
I think it would be great if you check if the wanted font family like "Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol", etc
are installed before fallback it, use the fallback based on the running OS is a pretty weak check.
Maybe this topic can help you about check if a font is installed on the browser
Please don't check for any specific font families. Users should be able to use whichever emoji font they want. Not some pre-approved whitelist that will be backed into software and probably not updated for decades.
@kevincox
I created a userscript to fix this on GitHub. I would be happy to accept patches for other sites, if any, that are using this component. https://userscripts.kevincox.ca/github-emoji-linux.user.js
Thanks for sharing this, it didn't work for me at first because of this, then I fixed it and it's working now 😄
the script version I'm using, if you wan't to check it out.
As you can see below, my emojis aren't the Github default ones anymore
Thanks for pointing that out. I've made a change that I think should make it work on Tampermonkey without requesting all permissions. If further discussions are needed we can do that here: https://gitlab.com/kevincox/userscripts/-/issues/1
For people using uBlock Origin (1.46.0 or newer), you can fix the issue with the following filter:
github.com##g-emoji:remove-attr(fallback-src)
It removes the fallback-src
attribute, which is required to replace the emojis with the images.
Most Linux desktop-distros (pre)install Google's Noto Color Emoji
Perhaps it'd be more helpful to those to add
Noto Color Emoji
to the list of fonts, rather than outright rejecting Linux.