Closed ajwang0 closed 3 years ago
mathiasbynens
commented
3 years ago Thanks for doing the research on this, @ajwang0! I’ll update our list of special cases accordingly.
FYI @rsheeter, we should update the font assets accordingly, and ideally also get Unicode’s emoji-test.txt updated to recognize as many of our special-cased sequences as possible. They must be supported to properly support real-world content anyhow, so the standard and its data files should recognize that.
mathiasbynens
commented
3 years ago @ajwang0 I noticed that in your original post, the following three emoji are not actually overqualified (the way you posted them):
'\u{1F538}', // 🔸
'\u{1F53A}', // 🔺
'\u{1F53B}', // 🔻Could you please double-check and confirm if we need to include these with added U+FE0F?
ajwang0
commented
3 years ago 🔸
You're right about these 3. I double checked and iOS does not send them overqualified.
mathiasbynens
commented
3 years ago Thanks! In that case I’ll land #10 as-is.
mathiasbynens
commented
3 years ago Fixed and released in v1.5.0!
iOS overqualifies some emojis with 65039 (variation selector). However these are non-compliant and do not follow the Unicode/Emoji standard. We should still handle scanning for these emojis since these are widely sent.
A list of some of the emojis that I came across include: