As a web, mobile or software developer, you’re probably including emojis in your application the wrong way. This is why.
Starting With An Example
The common mistake programmers make when it comes to include emojis in their application, is to simply copy them, for instance from a website such as Emojipedia, and then paste it into the source code.
This is also what I used to do.
- Source code:
<h2>
I'm a pretty header! 🎉
</h2>
- Output:
I'm a pretty header! 🎉
The Problem
As you can see, including emojis that way seems to work just fine. The emoji we copy-pasted is rendered the way we wanted, yee-haw!
Now, imagine being so proud of the application or feature you just created that you want to showcase it, let's say, to your grandparents.
As you might have guessed, your grandparents may not have the latest smartphone or laptop on the market. It might not display emojis at all, or just the emoji you used is not supported yet by their device.
Hence, this is what they could see:
I'm a pretty header! ▯
Probably not what you wanted them to see...
Why Does This Happen ?
From phonearena:
Emoji works exactly the same way as regular text — a Unicode code point corresponds to every character in the Unicode catalog, Emoji included. When a device sends a message, it sends a series of Unicode code points. When another device receives said message, it interprets the code points and displays letters, numbers and Emojis. It’s actually a bit more complicated than that, but this is the basic principle.
As you can see, the emoji is interpreted by the device, which means that their appearance may vary from one device to another.
Thus, it may not appear the way you wanted the user to see it, and possibly alter your application’s design…
The gift emoji, displayed by different devices.
The Workaround
Fortunately, whether you are a web, mobile or software developer, there is a quick and easy workaround for this problem, and that is Twemoji.
This open source project by Twitter converts Unicode emoji characters into normal SVG images, which are icons you can enlarge as much as you like without losing any quality — also known as vector images.
This way, your emojis will be displayed in the same way on all devices that are able to display images — which means, any smartphone and PC.
Now let’s dive into a concrete example. We’ll use the Twemoji library into our web application.
1. The HTML Code
<h1>
I'm a pretty header! 🎉
</h1>
<script src="https://twemoji.maxcdn.com/v/latest/twemoji.min.js" crossorigin="anonymous"></script>
<script src="app.js"></script>
2. The JavaScript Code
twemoji.parse(document.body)
Yes, that’s all you need! 😲
3. Adding A Bit Of Style
The previous code will create a new <img> element, with the emoji class.
<img draggable="false" class="emoji" alt="🎉" src="https://twemoji.maxcdn.com/v/13.0.1/72x72/1f389.png">
However, if we don’t add any CSS styles, this is what the output looks like…
Hence, just add these 6 lines to your CSS file:
.emoji {
display: inline-block;
width: 1em;
height: 1em;
vertical-align: -.1em;
}
We set the width and height the same as the surrounding text, and vertically center the emoji.
And now see the final output…
This is how your emoji will look like on all devices using your application. Awesome! Right?
Caveats
When using this library, you have to be aware that it will create additional requests. Indeed, the output code is an <img> tag, with a source attribute to the Twemoji's MaxCDN url.
This can be problematic if you want your application to be quickly loaded through poor internet connections.
Also, the Twemojis appearance may not be to everyone's liking.
Conclusion
Accessibility is important: your users should be able to see any content of your application. The little trick we’ve seen in this article is in fact used in Discord applications, and also in other famous ones — even Twitter itself.
Now, you can showcase your brand new projects to your grandparents, no matter what old device they are using. 😏
I hope this article was helpful for you! Will you now include Twemoji in your projects? Let me know in the comments!
Latest comments (35)
Nice trick,Best of Japanese Emoticons
getkaomoji.com/best-of-japanese-em...
Don't forget "emoji-to-ascii" in case your grandparent wants to access your website from a CLI....
I'm sorry, but please don't. As someone with vision-related sensitivities, I have to adapt websites to my needs. If you stick to font-based emoji, I can change the font. (I hardly use mobile apps except some light games and a couple of apps which happen to suit my eyes anyway.)
My actual problem is not emoji, it's glare and contrast issues. I use Dark Reader to eliminate the glare and increase the contrast. My greatest nemeses (wording intentional :p ) are interface designers who don't consider this use or who enforce their view of what their site should look like. The next level down is designers who use black-on-transparent icons for important things. Thankfully, that's rare these days. Things have got better in the last 10 years, please don't reverse the trend. Actually, the trend is already starting to turn with site scripts setting styles in some cases. I'll leave my feelings out of it because you wouldn't like what I have to say. :(
Thanks for your interesting feedback!
Great article!
I implemented this method on my 11ty personal website and it doesn't require client-side js as I parse them during build time.
Thank you for sharing. I don't want to use it in my project because I am lazy to add those redundant lines of code
How many grandparents are visiting your site?! ...
And another CDN ...
You can also use this method to display new emojis that haven't been supported on latest version of operating system yet. It typically takes 1-2 years for new emojis to get included.
That was just a funny Illustration for the fact that some users still have "old" smartphones 😉
Nooooo 🙀! Use the platform instead! Emojis are part of UTF, use them directly and no more libraries for this! Your grandparents who will have a bad connection will appreciate it as they will not need to download so many images.
You shouldn't write an article and propose people to use files and resources instead of standard device emojis. Or at least you should write down the drawbacks and not present everything like bells and whistles.
People with old browsers or devices should upgrade their browsers to access new features. You remind me some old folks that even today insist to support Internet Explorer and spend countless hours to make their HTML/CSS work on obsolete browsers just for some people with old browsers to be able to see their pages.
You throw away standards about how emojis should appear on each device and use external libraries to live traverse the HTML code of the document? That's a terrible thing to do. If I have an iPhone, I want all emojis to look like how apple wants them to look like in an iPhone. If I open the sites using Firefox, I want all emojis to look like how Mozilla emojis are look like. If you don't want to use the default emojis, then you want to use device independent SVGs to present graphic emojis and not standard emojis. In your article you're just using a horrible automation technique to parse the whole document.
Also keep in mind that Twitter emoji usability sucks. Just try to use them in your tweets and you'll see for yourself what I am talking about. You can't even select them because they are not using standards.
I actually disagree on your point that emojis should look the way the device the site is viewed on, intends them to look (when it comes to native apps I do agree though)
Your site has a design language, and your emojis should follow that design language, it shouldn't be up to the device to determine the design language itself.
Every site has its style and developers are freely to use SVG and graphics as they want and they should be aware of the consequences and the side-effects of their actions. Emojis are not a matter of how a font looks or how much padding/margin there is between some blocks, but it's tied to the devices. It's like respecting users preference for dark/light theme using CSS media queries like
@media (prefers-color-scheme: light)or@media (prefers-color-scheme: dark). Users are used to these emojis styles and especially for users with sigh disabilities these preference should be considered and respected.Why keep system/device emojis for native apps? You're saying that native applications cannot have their own unique style? I've created quite a few native apps all with different styles.
Personally I like when native apps follow the OS's design language, makes the whole seem more unified.
I think displaying a square on browser is bad for accessibility especially if you use the very new emojis and they aren't supported by latest Android and Windows. Different platforms display different styles might also convey different meanings. The way Twitter implements
alttext makes them not copyable. You can look at my website which I make them copyable.The square in the browser will happen in old browsers and even for newly added emojis, there will be updates that will be added to systems eventually. In our days, it's user's responsibility to have their browsers updated.
Also, different styles do not change the meaning, the meaning is the same, it's just the style that changes. Different platforms display different styles means that the users are used to these styles and we should not change that for them just because we want the emojis to look like we want them to look (or the style we think it's standard style). Use SVGs directly instead and not the standards; or use standard emojis and leave it to the system or the users’ preferences (which might be a different font more friendly to people with sight issues for example).
Having an automated document parser on each page load to change emojis with SVG assets is a terrible thing to do in many aspects. This should be done after saving an article and then the engine should render it (a markdown text to HTML maybe) and only then parse and replace the emojis.
I would argue for the
altusage. Alternative image text should not be used to have the actual emoji inside it but a description instead like Twitter. If you do it only for the selection thing it could be considered "OK".Agree with everything apart from the "You remind me some old folks that even today insist to support Internet Explorer" - we support IE back to IE9 due to the fact that disabled users who rely on screen readers often can't afford to update JAWS to the later versions and so are stuck on older browsers, some are even still using IE6-8 according to the most recent WebAim survey, but even I draw the line at supporting IE6,7 or 8!. You should at least support IE11 due to this fact (as 1 in 10 screen reader users still use it), even if it is a pain!
Is this really true? I am genuinely interested, as I've not run into this particular argument before. Personally I tend to use NVDA most of the time (for testing purposes) as surveys tend to put it as the most used (webaim.org/projects/screenreadersu... ) and it works on every browser across Windows. It being free for use is probably also what's contributed to its popularity.
Also, looking at the JAWS website, it doesn't appear to charge for upgrades.
I do believe the argument for supporting very old browsers/systems has to strike a balance. First, we must ask if that emoji is vitally important to the content? If it's not, why is it there at all, and can it be removed?
If we truly need it, then how much of our audience is likely to be affected by it not being there? Mac and Linux have support for emoji out of the box, and Windows has it with built-in updates (albeit non-essential) since Windows 7 (which is about 11 years old now). We could use this Twitter library, but then the cost is going to affect all of our users by increasing network traffic and decreasing performance. When you consider that even countries like USA have some areas with really poor Internet connections, that impact actually becomes much more noticeable (businessinsider.com/map-fastest-an... ).
Thanks for your comment!
@ashleyjsheridan Yes it is true.
We could make the argument similar to @christoslitras that "users should just use the latest tech" but there are loads of reasons why they don't (for example):-
With regards to JAWS cost it depends entirely on what country you are in as they use a distributor model.
In the UK to upgrade from 2017 JAWS or earlier to 2020 JAWS would cost you £375 as a home user. If you need it for work expect to pay double for a commercial license (although with a bit of fiddling and patience you can get that paid for by the government).
This is why NVDA is so popular (as you mentioned, it's FREE!), and it is a great piece of kit, but JAWS is still better with some programmes etc.
It is also familiarity, if you have used JAWS for 10 years then you know the shortcuts, the speech patterns, idiosyncrasies etc. Forcing someone to use NVDA and a certain browser is like me asking you to start writing with your left hand if you are right handed (or vice versa) in order to use my service.
You could do it but it would take a lot of time and effort so I am sure you would just stick with your right hand and just go to someone else who will let you write with the hand you prefer. (Not my best analogy but hopefully you get the point!)
I agree on the balance, it frustrates me that I have to still support IE9 - but I blame Microsoft for the issues I have with IE9 not my end users.
We choose IE9+ (rather than IE8+ etc) as our support level as that supports modern HTML and most CSS and compiling your JavaScript to work in IE9 isn't difficult.
When I say support IE9 I am not talking about pixel perfection, we can live with layout quirks and certain features not working perfectly as long as the site is still usable and fully accessible.
Also we support IE9+ for E-commerce sites, for SAAS we support IE11+ due to not wanting to have to create our own frameworks. We do however ensure that older browsers have alternative ways of performing critical actions.
That is just my 2 cents and why we support that far back, everyone is different, I just think it makes commercial sense to support things people still use as when they can't use your website as you don't support them they will hopefully come to mine 😊.
If you have your own site statistics and you can see there is a quite percentage of IE users using your site/services, then you and your team can decide if it's worth the time and effort to support such obsolete and abandoned browsers.
According to gs.statcounter.com, IE (all versions) global share is 1.68% and it keeps falling. Also many companies like Google, Facebook and even Microsoft, have stopped supporting IE for all new releasde of some very popular frameworks like React, Angular, Blazor/.NET SPA and even VueJS.
It does not worth it, not only for the time you or your team spends on this, but also having your site/app downloading and loading several JS/CSS files for pollyfilling missing features for obsolete browsers is bad for the projects ecosystem, for the majority of end users, for devices and even for the environment.
Agreed. The place I work at currently does have to support some older browsers, but that's typically more for core functionality rather than aestheitcal items. If things look a bit different, that's acceptable.
I suppose one could attempt to detect support of the emoji being used in a web page and use a method like this to fill them in, but again, is it worth it?
If you want to invest time and support IE8-10 then you or your team mates can do it, but Microsoft has officially ended support for IE8, IE9 and IE10 so NO; even users with dissabilities should update their systems and browsers to support latest standards.
I can agree just for supporting IE11 for now (maybe at least until next year) but not older version; is a much waste of resources and dev hours plus count the fact that these browsers need extra effort and time for proper accessibility features to work in the first place.
This. So much overhead to add when it's supported across every platform's last 4-6 years' worth of versions: caniemoji.com 😕
Thanks for this tool.
Interesting point of view, and you're actually right. I didn't talk about the drawbacks of using this library. Will definitely edit my article in the following days. 😉
Preword: this is a warning on the use of the library itself, not your article, despite the tongue-in-cheek title suggestion :-P
This should be titled "The one script that will kill your core web vitals".
If you used 10 different emojis on your page that is 10 extra network requests (plus one for the script itself), so your load speed will suffer!
Also I would imagine that your Cumulative Layout Shift would be horrendous due to the impact of inserting the images on the fly (and as such not allocating the correct space for them).
You would be much better manually inserting the SVG code for the emojis inline within the HTML if they are that important to your article.
If that much effort is not justified, then you know that is when you are using emojis the wrong way as they are simply not needed!
Additionally that alt text for the images will not behave well with screen readers as it appears to just be set to the emoji Unicode character, so from an accessibility perspective this is probably worse as you now have an image with a potentially useless alt description that will be announced instead of just an item that will get skipped (as screen readers have a notoriously bad time with emojis).
I would say avoid this at all costs for any site that needs traffic I am afraid (useful for personal blogs perhaps and the like, which I suppose are where emojis would be used anyway so perhaps I am just being stupid. hehe.)
I strongly agree, replacing a simple unicode emoji with a JS library that replaces the svg on the fly is a really, really bad idea.
If you do want to replace emojis with SVGs you should do it at a build step, automatically. Preferably all the SVGs would also be loaded as a single spirte-sheet to avoid multiple requests.
Personally I think that emojis are well supported enough to be used natively.
Thanks for your comment 😁
Not a problem, like I said (or should have said more clearly!) I enjoyed the article and it actually has made me think this is one step away from a good idea.
You could convert the code to server side code and replace all the emojis with inline SVGs before serving the page. The principal is sound just the implementation is bad, doing it on the server could actually be a useful solution.
Saved the library anyway and if at some point I get down my list of 50 "thats a great idea I will do that one day" items I may implement it as a server side library.
Honestly I didn't think about the fact that, indeed, this creates many requests if you put several emojis! Thanks for your advice.
P.s. I guess what you're looking for is the rectangle "save" button, isn't it?
No I found it, the big heart icon on the left to give your article some love was what I was looking for! hehe.
I do think emoji should be avoided, except for the sake of convenience.
Nice trick
I also use it in my blog, replacing the built-in ones with the consistent twemojis