I understand that emoji are used in-line with text, but they aren't text.
Once you start going the path of encoding pictures into a text representation you're going to start missing things that people need in these kinds of pictoral representations.
I'm sympathetic in a sense, I wrote a paper in college demonstrating why emoji/emoticons are a natural extension of text (to a point), because they can allow encoding emotion and intent, which natural language punctuation don't really allow for. But at the same time, is it really necessary to have half a dozen fish, trains, several food items an alien head, a full set of numbers from 1-10, squares of different sizes, and other non-emotional iconography?
And then the argument is that this is just intended to encode Japanese carrier emoji. Great, let's spend brain cycles building into unicode icons used by phone carriers in one country.
I'm already bothered by the separate encodings I've seen from time to time for the exact same script, but in slightly different font variations. That's supposed to be handled by the font that's representing the script, not by the encoding.
This really needs to be a separate encoding that's not unicode. I figure at some point, unicode will simply turn into a generic image format with a bunch of extra character encoding baggage that people will complain about.
That said, I guess I agree, if you're going to have emoji at all, you have to at least think about this issue. My inclination would have been to make them all green from the beginning, so there's no question of ethnic favoritism, but I guess it didn't happen that way.
Why? It's a useful and convenient pictographic addition to text, and it brings attention to astral characters and combining characters whose handling is routinely screwed up by western developers (let alone anglo-centric ones) who don't routinely deal with them and don't care to test for these cases. I mean it took until 2010 for MySQL to start not destroying astral characters at all (with the introduction of "utf8mb4" in 5.5(.3)). And oddly enough, one of the big world-wide changes to text content between 2006 (MySQL 5.1) and 2010 was emoji spreading outside of japan starting around 2008. I'd like to say it's a coincidence, but that's not really likely.
> And then the argument is that this is just intended to encode Japanese carrier emoji. Great, let's spend brain cycles building into unicode icons used by phone carriers in one country.
That's an argument nobody is making because emoji escaped japan back in 2008 when people outside japan started unlocking the emoji iOS keyboard and using emoji elsewhere.
> I'm already bothered by the separate encodings I've seen from time to time for the exact same script, but in slightly different font variations. That's supposed to be handled by the font that's representing the script, not by the encoding.
That doesn't really work, because now you can't mix the two languages anymore, this is actually a big issue with han unification, mixing Chinese and Japanese in the same text becomes a pain in the ass because they can't look right without a bunch of font-based hackery, which expects the client to have all the right fonts in the first place.
> This really needs to be a separate encoding that's not unicode.
And so you couldn't mix emoji and text, now that would be convenient and absolutely wouldn't lead to proprietary emoji implementations in private unicode fields at all.
Well it would actually because that's how emoji were first integrated in unicode in the first place.
More importantly, your history is all wrong. Emoticons have been used in the west since the telegraph and kaomojis (emojis) showed up in the 80s and have been known outside of Japan not long after.
These images are simply an interpretation of common emojis into graphical form, they literally map something like ^_^ to a smiley face.
Somewhere along the line, it was thought to be a good idea to let people just choose from common emoticons and have it map to the character implementation rather than doing the reverse (because remembering things is hard). On the receiving end, the ^_^ is simply replaced with whatever image the chat app has chosen to represent that.
Later, DoCoMo, KDDI and Softbank decided to further formalize the emoji codec mapping as part of Shift-JIS (and ISO-2022-JP) and that's why we have encodings for snail, minidisc and chicken leg, but not mosque, pork chop and blue jeans. Here's the mapping table https://docs.google.com/viewer?url=http%3A%2F%2Fwww.unicode....
What the logic was to do this is anybody's guess, but it was probably for bandwidth efficiency.
It would be more appropriate for there to be an entirely separate "expressions" standard for encoding various emoticon systems (there's several) and providing a standard iconography. You can already mix and match fonts and languages with images in most rich-text controls.
Unicode is not the correct place to do this. And amazingly, text-controls, as we have already established, can support fonts and images next to each other. So extending a text control to support unicode, images and expressions, would seem more logical than shoehorning shift-jis, which is not a human written language, into unicode.
Here's the original proposal that started this madness, so you can read the rationale. There's lots of people to blame for this, but we can start with the authors of this proposal.
 The Internet is primarily about cute kitties, not humans. And there are still no means to mark whenever U+1F431 (🐱) is black, or, say, silver spotted tabby.
U+1F400 EMOJI MODIFIER SMURF
U+1F401 EMOJI MODIFIER NAVI
U+1F402 EMOJI MODIFIER GREY
U+1F403 EMOJI MODIFIER GRAY
U+1F404 EMOJI MODIFIER REPTILIAN SHAPESHIFTER
But the real, important work will come with the modifier modifiers, e.g.
U+1F500 EMOJI MODIFIER MODIFIER EMBARRASSED
U+1F501 EMOJI MODIFIER MODIFIER SUNBURNT
U+1F502 EMOJI MODIFIER MODIFIER CHOKING
U+1F503 EMOJI MODIFIER MODIFIER DEAD
Another commenter mentioned the requirement for facial hair,
U+1F1330 EMOJI MODIFIER ANCHOR
U+1F1331 EMOJI MODIFIER BALBO
U+1F1332 EMOJI MODIFIER CHIN PUFF
U+1F1333 EMOJI MODIFIER CHIN STRAP
U+1F1334 EMOJI MODIFIER DUTCH
U+1F1335 EMOJI MODIFIER FIVE O'CLOCK SHADOW
U+1F1336 EMOJI MODIFIER GOATEE
U+1F1337 EMOJI MODIFIER HACKER BEARD
U+1F1338 EMOJI MODIFIER IMPERIAL
U+1F1339 EMOJI MODIFIER MUTTON CHOPS
U+1F133A EMOJI MODIFIER NECKBEARD
U+1F133B EMOJI MODIFIER SOUL PATCH
U+1F1430 EMOJI MODIFIER BOX CAR MOUSTACHE
U+1F1430 EMOJI MODIFIER CHEVRON MOUSTACHE
U+1F1430 EMOJI MODIFIER DALI MOUSTACHE
U+1F1430 EMOJI MODIFIER HANDLEBAR MOUSTACHE
U+1F1430 EMOJI MODIFIER PENCIL MOUSTACHE
U+1F1430 EMOJI MODIFIER PYRAMIDAL MOUSTACHE
U+1F1430 EMOJI MODIFIER TOOTHBRUSH MOUSTACHE
U+1F1430 EMOJI MODIFIER WALRUS MOUSTACHE
(Edit: I'm at 1338 internet points right now, so somebody needs to downvote me for this.)
Same applies to beards, of course.
Things that are universal to all humans. Will adding skin color to those emoji really enable better communication, or just create issues?
Anyway there's that Microsoft grey emoji too, but it looks a bit bland.
Certain groups hate the fact that the Internet allows people to overlook the boundaries of race, nationality and gender. It robs those groups of fuel for manufacturing outrage and leveraging it for political power. They'd love to "fix" it.
You think I'm wrong? Okay, then tell me this. Why can't we just color emoji a neutral color (green, blue) and be done with it? Nope, instead we're adding this insanely complicated stuff to Unicode definition.
Except that all of it needs to be translated to code, it involves operations with color (or multiplying the number of certain icons by 5), it needs to have a slightly different behavior (i.e. more code) on black-and-white screens, and so on. And just because there is already high level of complexity involved in something does not mean you should gleefully add to it.
The only thing which may have required more code is multi-color font glyphs and that's not a new things of emoji skin colors that was at best a new optional thing back when emoji were first introduced.
> it needs to have a slightly different behavior (i.e. more code) on black-and-white screens
More than that, I don't think I can provide any references now, but I remember some vulnerabilities caused by improper implementation of emoji alone in applications supposed to support them.
So both always were somewhat of a problem, except combining characters are obviously more important and hence more justified.
Now we have both combined. What unexpected behavior this will lead to? None of us can know.
There's no complexity to combining characters
But I agree, who really cares about the race of their emoticons?
This is my opinion about including emoji in Unicode, not the skin color modifiers.
I can only think of it as a case of bike-shedding. Han unification, indic scripts or the lack of differentiation between umlaut and diaeresis are difficult and require experts to be solve satisfactorily. Emojis are easy and anyone is able to contribute a little bit.
What is the scope of Unicode?
Unicode covers all the characters for all the writing
systems of the world, modern and ancient. 
so the unicode consortium could either standardise it,
or see the number of proprietary extensions increase
further and less and less people give a flying fuck
about their registry.
so the unicode consortium could either standardise it,
or see the emoji fad disappear as quickly as it appeared.
In particular I have no clue how popular they really were (only youth phenomenon?) and how many people somehow depended on them. In English or German you can get along quite well without emoji. Maybe communication in other languages depends more heavily on emoji because emotions can't be expressed concisely? Or is there another reason why they became popular in Japan first.
 it actually required "unlocking" the relevant keyboard by starting an application which used those characters or something like that, shit was crazy, it took several ios versions for apple to make the emoji keyboard available to any and all OOTB
Company logos are widespread on the web and in icon fonts.
145 of the 585 glyphs in Font Awesome 4.0.0 are brand icons This is one quarter. Of the 2000 icons in the Ultimate Icons Pack 354 are "social logos". Other fonts are similar.
I don't want to see them included in Unicode but I see more arguments for logos in Unicode than for emojis.
(Damn. Now I want it. Would be a perfect addition to any political discussion. And don't forget about COUNTRYBALL MODIFIER ANSCHLUSS EYES.)
In my personal opinion, that's more of rich text formatting (text with images), not extra characters anymore. That's debatable (and the debate's lost already, huh) but I still believe pictures (emojis) should've been a separate encoding, independent from Unicode, as there is a distinction between a grapheme and icon (yes, the distinction's very blurred by pictograms and ideograms - and I'm not sure I get all those things correctly, but still...)
I mean, there's a Moai head in this set.
Saying "the whole emoji thing" is like saying "the whole texting thing" in 2003 or "the whole internet thing" in 1997. They're here to stay, calling them ridiculous marks you as dated. Whether you care is up to you. 😜
So yay for unicode skin tones I say, just as emoji brought to light all the broken handling of astral characters out there, skin tones might finally bring some light to combining characters for all the anglo-centric developers out there who couldn't be arsed to learn about the issue when it didn't affect them.
I've always found the entire concept of reversing a string amusing enough, now I get to add another example of why the entire problem is ill-defined. What is the reverse of the 'white woman hearts black man' emoji? Is it a 'black man hearts white woman' emoji?
The realistic string handling problem this will at least bring to light is probably more likely to be an issue with strong truncation than with ill-formed interview questions. As you say, if this brings the risk of splitting combining characters to the fore maybe more software will handle it in the future.
> What is the reverse of the 'white woman hearts black
> man' emoji? Is it a 'black man hearts white woman' emoji
Another thing I learned is that there is a scale for skin tones, the Fitzpatrick Scale .
This to me is why emojis in fonts are so weird. Normal glyphs can be given a color (e.g. you have a red background so you make all your text white). Everything in Unicode can be reasonably changed to another text color, except for emojis. Heck, even old dingbat icon-fonts look good in any color! Emojis don't; they clash with practically everything that isn't a white background.
For example, on my iPhone, I tried using an emoji such as "📞" (telephone receiver) in an entry from my contacts list, and sure enough that is allowed. The problem is, this string is used in many contexts: during an outgoing call, names are shown in white on an arbitrary image background; in the contacts list, names are black; and there are probably other renderings too. The plain text looks fine in every case because the OS simply changes all the glyphs to the appropriate color; yet the "📞" icon looks terrible on the call screen because its appearance is unchanged and it looks a blob of goo that's hard to distinguish from the background.
There are usability reasons to have black-and-white icon designs, too. Mac OS X does this; such icons are less distracting and it's easier to see details at small sizes.
Basically I think they should've taken a close look at what dingbats fonts were doing, and just extend that concept further to have a host of new black-and-white icons.
This introduces a lot of complexity with little payoff; not a good engineering practice. Also, let us not forget what Bruce Schneier said: "Unicode is just too complex to ever be secure." Maybe it would be a good idea to stop spiraling the complexity out of control??
Q: Are emoji the same thing as emoticons?
A: Not exactly. Emoticons (from “emotion” plus “icon”)
are specifically intended to depict facial expression
or body posture as a way of conveying emotion or
attitude in e-mail and text messages. They originated
as ASCII character combinations such as :-) to indicate
a smile—and by extension, a joke—and :-( to indicate a
frown. In East Asia, a number of more elaborate
sequences have been developed, such as (")(-_-)(")
showing an upset face with hands raised. Over time, many
systems began replacing such sequences with images, and
also began providing ways to input emoticon images
directly, such as a menu or palette. The emoji sets used
by Japanese cell phone carriers contain a large number
of characters for emoticon images, along with many other
non-emoticon emoji. 
And if this becomes true, then we have to lock everything down, and we're back to ASCII. And then we have to start all over again.
7.0.0 Core Specification has exactly 1000 pages. This is only the prose of the core spec, the standard annexes and the character database is separate.
You should be thinking about how this feature interacts with every other feature implemented in Unicode. And how, for example, this feature will be brought into an existing Unicode parser.
There's always a straw that breaks the camel's neck. Or just leads to camels' quality to gradually deteriorate, leading to increasing bug rates and camel maintainers' depression.
To quote from another reply: "Can't wait to bring up this edge case the next time someone asks me to reverse a string in an interview."
Hell, now, 24 years late, you finally know about that issue and with a bit of luck you may not fuck it up next time you're doing that. That sounds like a great result to me.
It's a bit tiresome how people are so quick to tar orderly additions to technical things as "complexity".
Thinking about it, I want a Unicode hacker beard :)