Avoid Emoji as Class Names
The title of this post is not broad enough. Avoid emoji as any identifier, whether as strings in your script, IDs on your elements, classes for your CSS, and so on.
As soon as you start using emoji, you are blocking some users from being able to understand or use your code. It doesn’t matter how popular the technique becomes (or doesn’t).
This post leans on techniques I outline in my post Accessible Emoji, Tweaked to make the emoji I reference here accessible for a broader range of users.
Who Uses Emoji in Code?
A reason I have seen most trumpeted for using emoji are from those claiming a single emoji character can shave bytes off of files (versus long identifiers). Another common reason is that some developers consider them easier to recognize.
Granted, as more developers lean on verbose naming conventions like BEM, I can understand the appeal of
Who it Affects
Allow me to run at this with my experience working across countries, languages, and abilities. Maybe something will be familiar to you here. You may also have use cases beyond what I have outlined below.
Those on Disparate Platforms
Some platforms allow you to use emoji that are not rendered (or at least not rendered the same) on other platforms. While I have known about private-use Unicode ranges with custom emoji for years, I was not aware that a platform would allow users to easily access them. Or that their limited utility across platforms would not be presented to user. Until I saw one in a tweet.
While some on macOS or iOS may think that is a perfectly valid emoji to represent the Apple logo, for those on other platforms it renders as a square or some other glyph.
Bear this in mind if, for example, you want to denote a style specific to Apple users and maybe avoid emoji altogether, since it can be tempting to make a style declaration like
button. and never know that developers on other platforms will not benefit from the at-a-glance understanding you were hoping to convey.
This, of course, completely ignores the fact that many code editors cannot even display emoji (Emacs, for example).
Those Who Need More Contrast
I work in non-ideal conditions all the time. I work on airplanes, in airports, in cafes, on my patio, on my porch, in hotels, in restaurants, in libraries, and so in. In all these cases lighting is often an issue, sometimes with unexpected shards of sunlight shooting across my screen.
I can kick the contrast up on my text editors, turn my screen brightness all the way up, and even constantly turn to block the light. But when I am trying to tell the difference between two emoji whose shapes and colors are similar, this can be quite tricky. For example, 💿 and 📀 have gotten me (never mind how these render under the new Windows 10 grayscale mode).
Instead of just scanning an HTML file for class names referenced in CSS, I have to use a Find feature to locate the emoji in the code that matches the glyph in the CSS. This is an unnecessary waste of time for any developer.
Those From Different Backgrounds
This is pretty broad, but let’s consider that you are working on a team that is not made up exclusively of white middle-class twenty-something American guys. On the one hand, you want to code quickly. On the other hand, you maybe don’t want to create confusion with your efforts. Let’s take a couple easy examples that don’t give away my failure to understand the hip emoji of today.
So what do you when you want to reference multilingual content on a page? I have seen a flag used more than once to indicate a language, but that runs the risk of being completely misunderstood by speakers of the language as well as citizens of that country. For example, using the Portuguese flag (🇵🇹, which sometimes renders as the text PT) for a Portuguese-language section of a Brazilian site would be bad form, and potentially offensive.
Let’s go in a different direction and instead consider whether you want to render emoji that show people. Not just because the emotions conveyed by many of them are so confusing and potentially culturally varied, but also just deciding the skin tone can be tricky (think contrast issues again). I don’t know what 👨💻 is supposed to convey, 👌🏿 is not only a confusing gesture to many, but with this skin tone can be hard to see in my night-themed editor, and 😳 is so different across platforms that I have no idea what it even means.
Those Who Use Screen Readers
First, we need to remember that not all screen reader users are blind. For example, my vision is ace (sorta) but I have come to use screen readers for some mundane tasks. Screen readers also come in great variety, but we really only need one of the popular ones to fail to support emoji in code, and you will have just excluded an entire audience.
In this case, I think a demonstration is more powerful than just telling you what happens. I fired up Visual Studio Code (which supports emoji, unlike Emacs, for example). Visual Studio Code has a screen reader mode, so I dived in using both JAWS and NVDA.
I made another video using NVDA and Visual Studio Code on my other machine, which you are welcome to view, and it announces none of the emoji. So there is that too.
If you want to test it yourself, here is the code I used:
Those Who Want to Share
Note that when I tried to just paste that block of CSS into WordPress as-is, WordPress stripped some of the emoji. That’s why I opted to use CodePen, which itself struggles with rendering all the emoji. Which is another factor to consider should you ever want to blog a tutorial using emoji.
Identifying why these two platforms (WordPress and CodePen) behave the way they do is outside the scope of this post. Instead, it is worth just being aware that there is an issue in two (at least) popular platforms that developers use to share code.
Instead, ask yourself why you want to use emoji this way, and if the answer is just that it is for fun, don’t do it. Certainly not if you ever want to use it with anyone else.