[epidemian]

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]

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]

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.