Render unicode emoji with image fallback

(Moving discussion of rendering unicode emoji from #768 to a separate thread)

From #768:

According to caniemoji.com, unicode emoji are supported all the way back to Windows 7, macOS 10.7, Android 4.4, and iOS 5. Switching to unicode emoji would remove emoji <img> requests and render emoji native to each platform. Seems like a better route to go, so long as the unsupported OS+Browser combinations aren’t a concern. This article will likely be helpful if/when the switch to unicode happens.

[jhildenbiddle]

My initial thought was to just leverage the GitHub emoji API to get both the alias and the unicode value:

// API
{
  "+1": "https://github.githubassets.com/images/icons/emoji/unicode/1f44d.png?v8",
  ...
  "thumbsup": "https://github.githubassets.com/images/icons/emoji/unicode/1f44d.png?v8",
  ...
}

// Alias  : "+1" or "thumbsup"
// Unicode: "1f44d"
// URL    : "https://github.githubassets.com/images/icons/emoji/unicode/1f44d.png?v8"

GitHub has already done the work of mapping aliases to unicode values and images (the file name is the unicode value), as well as adding logical duplicates like the example above.

As for the implementation:

• Emoji data should be embedded in docsify.js, not requested from the GitHub API by the client.

• GitHub data should be transformed to better fit docsify’s usage and reduce client-side parsing. For example, instead of embedding GitHub’s API data as-is:

  {
    "+1": "https://github.githubassets.com/images/icons/emoji/unicode/1f44d.png?v8",
    ...
  }
  
  // const emojiURL  = emoji["+1"];
  // const emojiCode = emojiURL.slice(emojiURL.lastIndexOf('/') + 1, emojiURL.lastIndexOf('.'));
  
  

  The data should be transformed to allow fast unicode and URL lookups:

  {
    "+1": {
      unicode: "1f44d",
      url: "https://github.githubassets.com/images/icons/emoji/unicode/1f44d.png?v8"
    }
    ...
  }
  
  // const emojiURL  = emoji["+1"].url
  // const emojiCode = emoji["+1"].unicode
  

• An automated task should be added that refreshes docsify’s local copy of GitHub API data, transforms the data as described above, and stores the result in a file that docsify can import/require at build time.

• A test for emoji support will determine if a unicode character or image is rendered. I’d likely reference Modernizr’s emoji test and build from that. The test only needs to done one time, so the performance impact should be negligible.

• Some minor CSS tweaks may be required for unicode emoji characters, and it will most likely make sense to wrap them in a <span> tag with a unique class.

These non-breaking changes will provide the following benefits:

1. Improved emoji rendering performance by removing image requests on platforms that support unicode emoji
2. Rendering of native emoji on platforms that support unicode emoji
3. Additional emoji alias support (docsify currently support 886, GitHub support 1508)
4. Simplified emoji support for docsify devs (via automated task described above)

How does that sound?

[jhildenbiddle]

Depends on how important you think this is. My preference would be to focus on getting the repo up-to-date (PRs, IE compatibility, triaging issues, etc.) for the next release (4.x) and push enhancements (like this) off to the following release.