Block ™️, ©️ from emojification

[riking]

Forbid ™ ® © so they don't turn into black-on-black emoji.

I haven't figured out the docker-compose stuff yet so these changes haven't been tested yet. If someone else could make sure this runs that would be nice.

[ineffyble]

Is there a better option? Such as using a light/white version of the EmojiOne images?

[riking]

Emojione doesn't seem to provide that from what I can tell.

This is also an issue for emoji such as ✔️ ➗ 💲 ➖ ✖️ but those don't have quite as widespread font support for the Unicode versions.

[yiskah]

This does not seem like a good solution for this problem. What will happen is instead of returning an intended look it will return the string ":tm:" etc. which will be perceived as an error.

[riking]

Really? In my browser, the content of the alt attribute is ™, not :tm:.

[marrus-sh]

The Unicode solution for this is to use the Emoji Variation Selector U+FE0E to select text representations for glyphs; Apple etc will insert these for you whenever you insert a text version of an emoji, however EmojiOne doesn't respect them (joypixels/emojione#301, joypixels/emojione#415). Furthermore, EmojiOne defaults to emoji representations for all characters, including a number of characters which should (by the Emoji spec recommendations for web pages) default to text (for example, ™, ®, ©; again see joypixels/emojione#415). So this PR is actually a workaround for EmojiOne's bug and a good approach IMO; the right-hand column of this chart provides other characters which predate emoji or otherwise might be likely to have text representations. Of course, it would be up to us as to which (if any) of these we would implement.

(See also #349, which is the Mastodon version of this Issue before we realized it was on EmojiOne's side.)

I agree that using the alt attribute is less-than-ideal though; I don't have push access to this PR but the fix that I would suggest is here: https://gist.github.com/marrus-sh/71b3b4813e648ae4263e6a4e4b78c19a; note that this doesn't affect emoji inserted with shortnames at all (the assumption being that if you're using a shortname then you intended the emoji presentation), however I think Masto converts shortnames to character points now anyway so maybe that doesn't even matter. All I did was add an extra check to the str.replace function.

[marrus-sh]

This is something of a separate issue, but with respect to dark emoji not being visible, see also #317, especially this comment where I suggest using EmojiOne's Project B&W emoji for otherwise-unreadable emoji forms. Mastodon already uses SVGs for its emoji, so the changes that would need to take place would be as follows:

1. Tell Mastodon to pull from Project B&W SVGs instead of regular ones for dark emoji
2. Insert emoji using an <svg> element directly (through <use fill="currentColor" xlink:href="[emoji path]"> or similar) instead of through <img> and style that element appropriately. I'm like 75% sure that this will work. If not, then the emoji would appear as plain black, which would be the opposite of help.

[ticky]

It looks like emojione 3.0 fixes this (joypixels/emojione#415), but we can’t use it until emojione-picker updates its dependency.

[mjankowski]

I agree that we should let the supporting lib fix this problem and benefit from it when they do.