Emoji not working

[jhildenbiddle]

See docsify-themeable's emoji demo

• https://jhildenbiddle.github.io/docsify-themeable/#/markdown?id=emoji

It appears the CDN used for emoji images is having issues or is no longer used for this purpose by GitHub.

For example, this markdown:

:thumbsup:

Is rendered as follows by docsify:

<img class="emoji" src="https://assets-cdn.github.com/images/icons/emoji/thumbsup.png" alt="thumbsup">

Here's how tne same emoji is rendered as part of a GitHub issue:

<g-emoji class="g-emoji" alias="+1" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f44d.png">👍</g-emoji>

Note the rendering method (rendering an actual emoji character) and the use of a different URL as a fallback. The official unicode emoji list may be helpful if/when docsify's emoji output is updated.

[sio-funmatsu]

Is this OK? or should we use CDN?
https://github.com/images/icons/emoji/thumbsup.png

[dryruner]

+1 Same issue.

[jhildenbiddle]

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.

@sio-funmatsu -- Swapping the URL may be a workable short-term fix, but I wouldn't recommend it as a permanent fix since this same thing can happen again if GitHub decides to host their emoji images in a new location. If we go this route, I'd recommend using GitHub's emoji <=> image mapping available via https://api.github.com/emojis. If we wanted to stick with images long-term, it would be better to reference open source or (free) licensed emoji images available on a CDN such as EmojiOne. Docsify would qualify for a free license, allowing it to import the images directly into the docsify repo, which could then be referenced on jsDelivr for free. This would remove the dependency on GitHub's emoji images and add support for additional emoji as well.

[nic]

The issue lives here:

https://github.com/docsifyjs/docsify/blob/master/lib/plugins/emoji.js#L896

The new URL is: https://github.com/images/icons/emoji/

(removes assets-cdn.)

[dryruner]

When is this expected to be fixed?

[timaschew]

For me it makes sense to go for long term with native unicode characters.
But this would be a breaking change. I don't know how we can map the names we currently use for the unicode emojis, because they have ambiguous keywords. In contrast GitHubs are unique.

For instance if you search for grinning you will find two results by keywords (and even more where this is a substring of the keyword) but on GitHub it's unique.

So I suggest to do a quick fix and sticking for now to GitHubs emoijs.
We need to decide if we do very simple by adapting to the new URL, or using this endpoint: https://api.github.com/emojis which should be used only once. This is more complex since the markup cannot be generated synchronously anymore, because we need first to fetch the mapping from GitHub, which of course should be done only once per page load.

I just remembered: GitHub API has a rate limit: https://developer.github.com/v3/#rate-limiting

For unauthenticated requests, the rate limit allows for up to 60 requests per hour.

That sounds like a deal breaker to me. And I've just tested for the emoji API, it is affected as well:

{
  "message": "API rate limit exceeded for xxx.yyy.zzz.133. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
  "documentation_url": "https://developer.github.com/v3/#rate-limiting"
}

@docsifyjs/core what do you think?

[ClarenceL]

language flags are broken due to this, even docsify docs have broken images, hope this gets fixed soon

[jhildenbiddle]

This has been fixed in the docsify v4.9.1 courtesy of @louislivi.

Moving unicode emoji discussion to a separate issue (#779).