I remember back in 2020 when I wrote emoji-picker-element, I was sure that using native emoji fonts was the way to go, and that I was skating toward where the puck was going. *Surely* we'd figure out all these font problems in no time, right?

And yet, things are actually worse now:

- Windows still won't show country flags
- Chromium still won't fix this for us https://issues.chromium.org/issues/40766658
- Safari still ties emoji to OS updates
- Firefox's bet on Twemoji went very south: https://bugzilla.mozilla.org/show_bug.cgi?id=1796880

I'd like to say that this is something for standards to solve, but it's actually basically just browser bugs that the browsers themselves could fix but don't bother (likely because any web app that matters just ships their own bloated emojis-as-images anyway).

It's also unfortunately not the kind of thing you could fix with Web Plat Tests, because the Unicode Consortium mints new emojis every year, so the test is outdated as soon as you write it, and doesn't solve Safari version fragmentation.

@nolan last time I was looking at emojis and fonts it looked to me like the main problem is that there are two or three different standards for how emojis can be encoded inside a font and rendered, so you can't just provide a font to your website viewers and be done with it. You would need 1 font for windows, 1 font for Mac, etc etc.

Is that still the case ?

Iirc I was trying to figure out how to get a consistent emoji look across all platforms and it seemed like tools to do that by constructing one of each type of font from source images or from a source font don't exist (well, besides using images like you said)

If I understand correct this is actually an OS font rendering thing not a browser thing ? All the sub pixel rendering stuff for fonts being different, and different mega corps each building thier own separate way to do emojis