4 ms·

A very welcomed initiative! I'm curious though: why is it necessary to store the emoji characters as :shortnames: in the DB instead of using the corresponding

A very welcomed initiative! I'm curious though: why is it necessary to store the emoji characters as :shortnames: in the DB instead of using the corresponding Unicode characters, and then convert them to image tags when rendering them to HTML[1]? Couldn't the Unicode characters be rendered directly on the HTML and then the emojis shown using a custom font via @font-face? Firefox at least seems to support this using color SVG fonts[2]. I think that would be a better solution, as it would allow copy&pasting text that includes emojis. Doing so in the current Emoji One demo page copies the emojis short names instead of the Unicode symbols. And it may even let the native emojis take precedence over the Emoji One set doing (I think): body { /* Use sans-serif before Emoji One to allow rendering native emojis. */ font-family: 'Open Sans', sans-serif, 'Emoji One'; } [1]: https://github.com/Ranks/emojione#installation https://github.com/Ranks/emojione#installation [2]: http://people.mozilla.org/~jkew/opentype-svg/GeckoEmoji.html http://people.mozilla.org/~jkew/opentype-svg/GeckoEmoji.html

emitstop 12y ago
You can store just the unicode characters to the db if you wish, the conversion script can convert both unicode, shortnames, as well as ascii text :-) to the images/svgs. Storing the :shortnames: was just our suggestion because we've found that many web stacks aren't setup to handle multi-byte/UTF-8 characters by from the get-go. Doing it this way is an easier over-all approach, but by all means feel free to take our tools and customize to your own needs. @font-face would definitely be the ideal solution, and hopefully something we can implement once the browser support is there, but at the moment we're trying to go for the most universal approach.
- epidemian 12y ago
  Thanks for replying! > @font-face would definitely be the ideal solution, and hopefully something we can implement once the browser support is there, but at the moment we're trying to go for the most universal approach. That's very reasonable. I wonder if there would be any problem if, instead of generating image tags like: <img alt="heart_eyes" class="emojione" src="//cdn.jsdelivr.net/emojione/assets/png/1F60D.png"> The JS toolkit would generate something like: <img alt="😍" class="emojione" src="//cdn.jsdelivr.net/emojione/assets/png/1F60D.png"> This should be pretty safe i think, as it's only client side, and browsers play nice with Unicode. That change allows the browser to copy, for example, the text "What's not to 😍 right?" from the Welcome page, instead of copying "What's not to heart_eyes right?" (tested on Firefox/Ubuntu).
  - flomo 12y ago
    The question is whether screen reader software deals well with the unicode emoji characters. I would lean towards the conservative assumption that it doesn't. Even Chrome/Mac still shows a missing character box rather the emoji. (Also that sentence needs a comma. "What's not to heart_eyes, right?")
  - emitstop 12y ago
    That'd be a great balance, and something we're going to look into. It does however, complicate the conversion script so as to not accidentally replace Unicode characters contained within the <img> tags, so it'd require a fair amount of testing.

emitstop 12y ago

You can store just the unicode characters to the db if you wish, the conversion script can convert both unicode, shortnames, as well as ascii text :-) to the images/svgs. Storing the :shortnames: was just our suggestion because we've found that many web stacks aren't setup to handle multi-byte/UTF-8 characters by from the get-go. Doing it this way is an easier over-all approach, but by all means feel free to take our tools and customize to your own needs. @font-face would definitely be the ideal solution, and hopefully something we can implement once the browser support is there, but at the moment we're trying to go for the most universal approach.

epidemian 12y ago
Thanks for replying! > @font-face would definitely be the ideal solution, and hopefully something we can implement once the browser support is there, but at the moment we're trying to go for the most universal approach. That's very reasonable. I wonder if there would be any problem if, instead of generating image tags like: <img alt="heart_eyes" class="emojione" src="//cdn.jsdelivr.net/emojione/assets/png/1F60D.png"> The JS toolkit would generate something like: <img alt="😍" class="emojione" src="//cdn.jsdelivr.net/emojione/assets/png/1F60D.png"> This should be pretty safe i think, as it's only client side, and browsers play nice with Unicode. That change allows the browser to copy, for example, the text "What's not to 😍 right?" from the Welcome page, instead of copying "What's not to heart_eyes right?" (tested on Firefox/Ubuntu).
- flomo 12y ago
  The question is whether screen reader software deals well with the unicode emoji characters. I would lean towards the conservative assumption that it doesn't. Even Chrome/Mac still shows a missing character box rather the emoji. (Also that sentence needs a comma. "What's not to heart_eyes, right?")
- emitstop 12y ago
  That'd be a great balance, and something we're going to look into. It does however, complicate the conversion script so as to not accidentally replace Unicode characters contained within the <img> tags, so it'd require a fair amount of testing.