> Do not store emoji unicodes in your database. Store the human-friendly code and support the emoji-cheat-sheet.
I would strongly recommend doing the reverse: store and use standard Unicode throughout your application. If you want support on browsers which do not support Unicode 6 properly, use JavaScript or a web font to substitute the characters in question so you don't need to update every bit if text you've ever stored or displayed when e.g. Chrome lands emoji support in a few releases.
This approach avoids having to fix your proprietary encoding scheme later and also means that less popular user agents automatically get support as soon as they add it.
I agree in principal, but in practice no such font is widely available. The emoji cheat sheet has emerged because a desire to use emoji exists, but both input and display are not well supported. The solution I propose, albeit imperfect, works today to display emoji input to those who would not otherwise see it.
There is at least one open font (Symbola) with emoji support and I thought Ubuntu had been adding support at some point recently.
More to the point, however, you could take the symbols you would have to create either way and package them as a web font - which would only be downloaded on devices without a better choice - or simply make your JavaScript do a simple search and replace on the Unicode character values to substitute the same HTML markup you'd need either way. Again, you could do a client side detection for this to avoid any overhead on browsers with support.
> GitHub introduced emoji pngs throughout their application, and pull requests are much better for it. Campfire supports emoji, and your professional interactions are much better for it.
I think I disagree. I'm trying to think of a situation in which a pull request or a campfire chat with emoji has ever made my life better, and I just can't.
Agreed, the use of emoji or the occasional ";D" is a measure of how informal the communication is, and isn't something that'll help improve the professional tone interacting with a client. I personally don't think it has much place in business communication at all, but that's just my personal preference.
If you can't communicate successfully without emoji, then you have a large communication problem that is likely not being solved by their addition.
why oh why would anybody want to have any piece of text looking like my little's brother 1993 geocities webpage, and why do we need to clutter text encoding with this?
if you want to put pictures in your text, just put pictures in your text. html has allowed you to do this since its inception.
Any chance Apple, Github, or Campfire have their emoji png icons available for download? (with a good license?) If not, what would be a nice set of emoji png's I can use for my website?
> Do not store emoji unicodes in your database. Store the human-friendly code and support the emoji-cheat-sheet.
I would strongly recommend doing the reverse: store and use standard Unicode throughout your application. If you want support on browsers which do not support Unicode 6 properly, use JavaScript or a web font to substitute the characters in question so you don't need to update every bit if text you've ever stored or displayed when e.g. Chrome lands emoji support in a few releases.
This approach avoids having to fix your proprietary encoding scheme later and also means that less popular user agents automatically get support as soon as they add it.