Color Emoji in Windows 8.1 – The Future of Color Fonts?
opentype.info
opentype.info
Printing for example would retain the meaning without a gray-scaled rendition losing the details to understand what the symbol might be. (This is just a guess, not an assertion that black-and-white symbols would be used in this context.)
From an accessibility standpoint, consider situations where high-contrast (and or size) is necessary, and it is perfectly legitimate to throw out or ignore the text and background colors for such users.
This solution seems to best satisfy comprehension needs for disabled users as well as printers--not that we need to print the bible translated to emoji any time soon.
In particular, it expands on the details behind Adobe/Mozilla's SVG approach, as well as browser support.
Note to site designers: something is terribly wrong if JS is needed to render the main textual content of your site.
Web browsers are an execution environment, no longer just document viewers.
And, I do enable JS when I am on a familiar / trusted / interesting site. I definitely won't enable it on an unfamiliar / blank looking website.
Indeed they are. But there is a real duality here. On HN, I see links to both applications and documents. Both of them happen to be HTTP links, since the web supports both.
I am mostly interested in the documents.
If you have a document to present, perhaps you should present it as a document, instead of requiring users to run your application to present your document?
It's nice to be able to rely on JS being there, just like it's nice to rely on having the correct DOM constructed since HTML parsing has been standardised. There are things that are much easier to do this way.
$("#content").makeResponsive();http://motherfuckingwebsite.com/
>This site doesn't care if you're on an iMac or a motherfucking Tamagotchi.
The only downside seems to be a limited color palette, but I don't think that outweighs the benefits, and also encourages a clear and simple design.
Is this a cultural thing I'm missing?
It may also be in part due to the complexities of asian languages. (Note that this latter part is complete conjecture)
As someone else mentioned, the two layer input systems used by these languages also make inserting an emoji pretty much the same as typing any other word.
(I'm sounding like a right grumpy old git here)
Emoji can certainly stand in for text, and I see plenty of comments and text messages that consist primarily of emoji. But just as often they will accompany text to add personality or mood the way ASCII smilies or textual kaomoji always have on bulletin boards.
Now that I think about it, you're completely write. It's been years since I've seen text-speak.
Compare the following mentioned during a code review:
Your code is crap Your code is crap :-)
The first is taken seriously, the second is more of a sarcastic joke. The meaning conveyed is even stronger when the picture is a comical and brightly coloured smiley face rather than an ascii smile.
There is also much more history of their (easy) use on iOS than Android, which did not support them very well, if at all, until recent years.
Recently getdavidhiggins posted a link on HN to http://emoj.li/ - an Emoji only chat. So it seems to be growing in popularity/ubiquity
That's a reason it is so heavily used in Japan, where they already have a two layer input system anyway. We might also have it easier and easier in ascii based languages as autocomplete like features develop and become ubiquitous.
Some Japanese keyboards will sometimes suggest emoji during input conversion (the normal kana->kanji step), but it's a somewhat haphazard way of inputting them, and it's often easier just use the dedicated emoji input. The reason seems fairly clear to me: many emoji encode nuances that don't map easily to single words or small compounds in a way that's easy for a user to predict...
[My old non-smart phone would suggest some emoji during input conversion (e.g. if you convert "ねこ", it would suggest "🐱" and "(=^ェ^=)" as well as "猫"), but my current (Japanese) Android phone doesn't seem to do any of that at all (using the vendor Japanese keyboard); to input emoji you need to use the emoji input... :]
Anyway, the main point I'm trying to make is that the method of Japanese language input doesn't seem to adequately explain why emoji are so popular in Japan, because the support for conversion-based emoji input is haphazard even in Japan.
About the android phones, I was a bit surprised by the low quality of Japanese support. But I didn't try the ATOK keyboard nor the input available on Sony phones for instance, only the Google IME. To Apple's credit, they've been doing IME on the mac for long enough to have a very good integration of the emoji in the system dictionary.
But really, my point was not only on the colourful emoji, but more on the fact that characters like ↑,♡,◎,△ are just unusable on a daily basis on a US/european computer, but are super easily summoned on a system with an IME. And Japanese people have been using these kind of pictograms in their communication for decades, the emoji used on the phones being just an advanced kind of the same thing. I think that would be the main cultural difference regarding to emoji.
The main issue with conversion-based emoji seems to be discoverability.... Besides those reflecting basic concepts, there are tons of odd or intricate emoji that you'd never even imagine existed unless you saw them first; even once you know they exist, figuring out what input maps to them is at best a crap shoot (I've never found any way of getting the input system to tell you)....
[0] http://matsucon.net/material/dic/kao01.html [1] http://plaza.rakuten.co.jp/love2kaomoji/5007/
The technical approach is smart, but lazy, and the resulting emoji look bland and lack definition. No wonder, since this approach doesn't support the way artists work. It's not SVG, it's not PostScript, it's not a bitmap, it's just a glyph sandwich. No opacity, no gradients, no effects. It must be a pain to split your pictures in layers so they can be in a font like that.
As far as using this for text... the novelty of such effects faded out sometime in the 90s when Word Art was all the rage among design-blind office workers.
In the modern world of Unicode, it's even less likely we'll start making fonts with hardcoded layers of cheesy effects when you need to cover a good range of international characters, weights, cursive, hints, kern pairs, ligatures, alternate versions and so on.
Well thank god. What you call "opacity, gradients, and effects", I call "total inability to be bolded, colored, embossed, etc." Apple's and Google's emoji basically entirely ignore CSS in favor of looking, well, exactly the way they look. Styling emoji to actually fit your site's theme? Who'd have imagined?
When you set your text to be bold, that's a separate font, made by a human hand.
Browsers have a fake bold look when the font is missing, but it's not a look you want on your site. They just, well... smudge it to the right. For Emoji the fake bold look is disabled, because bold or italic emoji is just non-sense on the face of it, so they don't support weight settings.
Also, you can't set the color of Windows Emoji via CSS. They're already colored.
Because the colored glyphs use a palette instead of hard-coded colors, it's possible to assign semantic meanings or names to each palette entry and remap them. This would enable you to render a 'high contrast' version, or adjust the primary color of an emoji (for example, changing the skin tone of a face), etc.
The latter is actually a topic of concern: Most current emoji represent a caucasian or light-skinned individual, so the lack of emojis that represent other races is a problem. People are still figuring out how to deal with it.
This solution is totally different, building up the color emoji using a cool font table approach. You should read it; it's worth the time. :)
EDIT: typos