fix: newer emoji and flags on Firefox on Windows

[nolanlawson]

Previous discussion: #268 (comment)

On Windows and Linux (but apparently not MacOS or Android), Firefox ships its own "Twemoji Mozilla" font. On Windows in particular, the conflicts with the existing Segoe UI font, causing several issues:

• Older emoji render in Segoe, newer emoji render in Twemoji
• Transgender flag renders as double emoji
• England, Scotland, and Wales flags render as black flags

This PR changes the order of fonts in the font-family list to put "Twemoji Mozilla" first. I'm just going to assume that, if Mozilla is bundling their own font in the browser, then they know what they're doing and they're shipping emoji updates faster than the underlying OS.

This assumption will break if the underlying OS emoji (i.e. Noto Emoji on Linux and Segoe UI on Windows) ever update faster than Mozilla Twemoji, but I guess we have to take that risk. Today Mozilla Twemoji is on v13.1, Segoe is on v12.1 (on my Windows 10 21H2), and Noto is on v13.1 (on my Ubuntu 20.04).

Before:

After:

MacOS and Android are unchanged because Mozilla doesn't ship Twemoji there. Linux is unchanged because we already listed Twemoji before Noto.

[github-actions]

📊 Tachometer Benchmark Results

Summary

benchmark-total

• emoji-picker-element-database-interactions: unsure 🔍 -5% - +3% (-8.56ms - +5.38ms)
  ^{this-change vs tip-of-tree}
• emoji-picker-element-first-load: unsure 🔍 -8% - +7% (-6.77ms - +6.38ms)
  ^{this-change vs tip-of-tree}
• emoji-picker-element-second-load: unsure 🔍 -3% - +10% (-2.10ms - +8.05ms)
  ^{this-change vs tip-of-tree}

Results

emoji-picker-element-database-interactions

• Browser: chrome-headless 98.0.4758.102
• Sample size: 50
• Built by: Benchmarks #153

• Commit: c576927

Version	Avg time	vs this-change	vs tip-of-tree tip-of-tree
this-change	157.18ms - 167.00ms	-	unsure 🔍 -5% - +3% -8.56ms - +5.38ms
tip-of-tree tip-of-tree	158.74ms - 168.62ms	unsure 🔍 -3% - +5% -5.38ms - +8.56ms	-

emoji-picker-element-first-load

• Browser: chrome-headless 98.0.4758.102
• Sample size: 50
• Built by: Benchmarks #153

• Commit: c576927

Version	Avg time	vs this-change	vs tip-of-tree tip-of-tree
this-change	83.12ms - 92.45ms	-	unsure 🔍 -8% - +7% -6.77ms - +6.38ms
tip-of-tree tip-of-tree	83.35ms - 92.61ms	unsure 🔍 -7% - +8% -6.38ms - +6.77ms	-

emoji-picker-element-second-load

• Browser: chrome-headless 98.0.4758.102
• Sample size: 70
• Built by: Benchmarks #153

• Commit: c576927

Version	Avg time	vs this-change	vs tip-of-tree tip-of-tree
this-change	83.29ms - 90.44ms	-	unsure 🔍 -3% - +10% -2.10ms - +8.05ms
tip-of-tree tip-of-tree	80.29ms - 87.50ms	unsure 🔍 -9% - +2% -8.05ms - +2.10ms	-

_{tachometer-reporter-action v2 for Benchmarks}

[github-actions]

Size Change: 0 B

Total Size: 41.8 kB

ℹ️ View Unchanged

Filename	Size
./bundle.js	41.8 kB

_{compressed-size-action}

[eteeselink]

At the risk of chipping in unsolicited: I'm not 100% convinced that this is the right solution, because the user tends to pick an emoji into something - likely a text field of sorts, and it'll be a quirky experience for the emoji picker to show Twemojis everywhere, but then when an emoji is picked, it'll show in the Segoe UI style again which looks quite different, to the point that I can imagine some users think they picked the wrong emoji. I guess the workaround is for every app that uses emoji-picker-element to also add Twemoji Mozilla to their font lists everywhere emojis could be shown, but it's still a bit surprising.

That, or I'm missing something :-)

[nolanlawson]

@eteeselink No problem with unsolicited feedback. 🙂

Yeah, it's a bit unfortunate, but the best way to ensure that your app renders exactly the same as emoji-picker-element is to copy over its font-family. This is what I do in my own app, Pinafore.

An alternative you might imagine is to just not specify the font-family at all! Unfortunately this results in worse behavior: some early emoji (like "smiling face" and "heart") render as black-and-white on some browsers. E.g. here is Chrome on Windows and Chrome on Ubuntu:

Also, that causes Firefox on Windows to still do the mixed font behavior:

I should really document this, though, since it's not at all obvious.

[nolanlawson]

In related news, it looks like Noto has released v14 whereas Mozilla Twemoji hasn't yet updated to v14 (mozilla/twemoji-colr#64). So possibly some Linux users are going to get a mix of Twemoji and Noto.

I'd still prefer putting Twemoji first, though, because I don't want to play a cat-and-mouse game of updating the list of fonts every time a browser or OS does a release.