Docsify: Render unicode emoji with image fallback

Created on 21 Feb 2019  路  7Comments  路  Source: docsifyjs/docsify

(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.

enhancement

Most helpful comment

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?

All 7 comments

What is your idea to support GitHub based aliases? I don't see any unique short names on this page: https://unicode.org/emoji/charts/full-emoji-list.html
On another I saw some other project which use the same source, but there are ambiguous keywords which are assigned to multiple emojis sometimes.

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?

BTW, there are quite a few GitHub emoji lists generated from the GitHub API that we can direct users to:

We should either reference once of these or provide our own auto-generated table in the official documentation.

Sounds very good! Thanks for providing all the details.

I see now that the unicode is available in the URL 馃檲

One suggestion: Some emojis have multiple unicode units/blocks? for example flags:

{
  "norway": {
    "unicode": ["1f1f3", "1f1f4"],
    "url": "https://github.githubassets.com/images/icons/emoji/unicode/1f1f3-1f1f4.png?v8"
  }
}

I've just realized, that the emojis on unicode.org have sometimes more than two units, but on GitHub they have maximal two units always. For instance the hash has three units on unicode.org
and on GitHub only two: https://github.githubassets.com/images/icons/emoji/unicode/0023-20e3.png?v8

But both variants are working.

Which milestone for this issues? 4.x or 5.x

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.

@sy-records handled this in https://github.com/docsifyjs/docsify/pull/1188

If we want to improve on it (f.e. make a bot to keep it updated, etc) let's open new issues for each update.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jhildenbiddle picture jhildenbiddle  路  3Comments

dooart picture dooart  路  5Comments

sijakret picture sijakret  路  3Comments

anikethsaha picture anikethsaha  路  3Comments

nothingrandom picture nothingrandom  路  5Comments