Incorrect rendering in native mode depending on browser
See original GitHub issueI am looking into using native
emoji to avoid having to download megabytes of spritesheets (and nudge users into upgrading their OSes 😉); but I’m getting some really weird cases of inconsistent rendering on the widget and I have no idea on what is the cause or the solution.
For example, here are captures from the demo page at https://missive.github.io/emoji-mart/:
Firefox | Safari (the only working example) |
---|---|
![]() |
![]() |
The situation gets even more confusing and chaotic when I actually try embedding it in my webpage:
Firefox (same issue) | Safari (wtf) |
---|---|
![]() |
![]() |
At first I thought this could be a problem related to my global styles, or even the font being used, but no matter how many styles I toggled off I still got the crazy results in Safari. Not sure where to go from here, other than giving up on native.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:3
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Fix web compatibility issues using document modes and ...
Go to a site having compatibility problems, press F12 to open the F12 Developer Tools, and go to the Emulation tool. · Starting...
Read more >Handling common HTML and CSS problems - MDN Web Docs
With the scene set, we'll now look specifically at the common cross-browser problems you will come across in HTML and CSS code, and...
Read more >7 Common Cross Browser Compatibility Issues to Avoid
4. DOCTYPE Error. This usually involves some kind of faulty rendering due to missing a basic line in the code. Browsers with outdated...
Read more >Strict Mode
StrictMode is a tool for highlighting potential problems in an application. Like Fragment , StrictMode does not render any visible UI. It activates...
Read more >React Native - How to reload colors based on Dark Mode ...
I had the same problem and solve it with the code bellow: const [colorScheme,setColorScheme] = useState(() => Appearance.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
A friend helped me debug this, and these are some things I’ve learned. They each depend on the browser being used.
Chrome: our html
:root
has alang
attribute that is set to"ja"
for most users. Setting thelang
to any value that is not recognized as a validlang
(say,lang="jp"
,lang="zzzzz"
orlang=""
), or set it toen
, actually makes it render correctly. Thelang
tag can be set locally, so it might be worked around byemoji-mart
through settinglang=""
on thespan
s that render emoji. This is likely a Blink bug.document.documentElement.lang = 'ja'
reproduces it in the demo page.Safari: We, for some reason, have a global
div { word-wrap: break-word; }
reset. Disabling it, or setting it tonormal
in.emoji-mart-category, .emoji-mart-preview-emoji
made the emoji combine correctly in it, regardless of thelang
settings. It did nothing on Chrome, though; onlylang
worked there.document.body.style.wordBreak = 'break-word'
(orbreak-all
) reproduces it in the demo page.I could not find anything that would work on Firefox; but it’s also broken in the demo page, so it’s not something caused by our page’s environment.
There’s nothing much we can do about browsers not supporting some native emojis, especially when it’s the result of the addition of 2 supported emojis that isn’t. For example: ✌️ + 🏻 = ✌🏻. Some browsers (on outdated OS) will render it like so:
I would suggest not using the native set when you don’t control in which environment it is displayed.