feat: Emoji plugin

[jaredcwhite]

It'd be great to have a plugin to convert colon codes like :+1: into 👍.

There's already support out there in the Kramdown and Jekyll ecosystems, so just need to figure out the best way to move forward here.

[andrewmcodes]

Seems like it wouldn't be too hard now that we have the HTML & XML Inspectors API 🤔

[andrewmcodes]

I had a look at the recommended 11ty plugin for emoji and to my surprise, borderline delight, they aren't actually replacing every emoji with an image to github.githubassets.com or somewhere similar, they are just ensuring that the emoji is accessible.

<!-- {% emoji "🙈" %} or {{ "🙈" | emoji }} -->
<span aria-hidden="true" class="eleventy-emoji" role="img">🙈</span>

<!-- {% emoji "🐵", "monkey face" %} or {{ "🐵" | emoji: "monkey face" }} -->
<span aria-label="monkey face" class="eleventy-emoji" role="img">🐵</span>

I would actually argue this is a more modern, performant, and accessible approach vs. replacing :+1: with images. It also is a way simpler plugin to maintain than the alternative and basically says that this is the way Bridgetown recommends.

What this doesn't solve is the fact emoji's look different on all platforms since they aren't using an image file and I would argue that that's the deal with using emoji and replacing with small images isn't necessarily a better solution than just designing with that in mind.

Would love to hear your throughts on where we are heading with Assets, Web Components, and A11Y in the next year on Fullstack Ruby sometime even just briefly! 🙂

[sandstrom]

Seems like it would be great for a third-party plugin, but maybe not in Bridgetown Core? I'd vote for closing this issue.

[brandondrew]

I can't argue with @sandstrom that it makes more sense as a plugin, but it would be sad if it got dropped because of that.

I also agree with @andrewmcodes that it's better to use real emojis. I personally hate the way Discord & Twitter &c. replace beautiful macOS emojis with really ugly images that look like they were designed to work on Windows 3.1 with 8-bit graphics.

The problem of emoji differences is indeed a problem, but I don't think using ugly images is the right solution. It seems to me to be outside the scope of what a plugin can solve. (The real solution IMHO would be an app that let you mouseover your OS's native emoji and then showed you in a popup window how the emoji appeared on other OSs. This allows you to perceive when other users might understand the emoji's meaning differently, which is not always as evident with images, which could "split the difference" between how the emoji appears on one OS and another. I think it was an Android bug that has been fixed, but I've seen cases where there was a very different emotion expressed depending on the OS. This sort of problem is always a risk, even if it might be less likely now.)

The biggest problem I foresee with such a plugin is that different people have learned to associate different "colon codes" with various emoji. (I use an app called Rocket on macOS and it never ceases to amaze me that the author did such a horrible job of giving names to the various emoji. For example the faceless sun emoji does not appear in the list when typing the word "sun".) Allowing people to create their own configuration file with names for emoji could

1. allow everyone (with some work) to overcome the fact that the maintainers won't anticipate every name they want to use, and
2. allow people to add emojis that the maintainer hasn't had a chance to add yet.

It would be nice if people could also easily submit their config files to let the maintainers see what they might have missed.

[brandondrew]

I know GitHub already has a gem for their "colon codes", but it would be helpful to also have dictionaries for Slack, Discord, and any other app that can automatically replace codes with emojis or images. It might be useful if each user could just configure Bridgetown to include whichever dictionaries they like and exclude whichever they don't. If you're a GitHub and Slack user, you already have certain mappings in your head, and you'd probably prefer to use those in Bridgetown too.

[sandstrom]

The problem for every open-source project is that there are more wishes than there are contributed hours.

Also, even when someone contributes a flawless patch which takes 1 second to review, doesn't slow down the system or introduce any downsides, it's still have to be maintained for the lifetime of the project (rarely will the patch contributor do this for eternity).

This is the main benefit of a plug-in system. Keeping a slim core and leaving other things for plugins, makes it somewhat easier for an open-source project to survive over a longer time period.

(EDIT: these are my own thoughts, not necessarily those of the bridgetown project, in which I have no role, apart from being a happy user of it)

[jaredcwhite]

@sandstrom To be fair though, "slim core + plugins" isn't quite a goal of the Bridgetown project. See: https://www.bridgetownrb.com/docs/philosophy#core-principles

If emoji text conversion seemed like it would receive enough potential usage, I'd be fine with adding it to core.

@brandondrew I appreciate you outlining some ideas and possible solutions to this. If we do reevaluate this in future, I'm sure that would prove extremely helpful.

[sandstrom]

@jaredcwhite Good point, I clarified my comment above.

If emoji text conversion seemed like it would receive enough potential usage, I'd be fine with adding it to core.

Two thoughts on this:

• I think Rails (and other frameworks) have been fairly successful in providing "primitives", simple building blocks, such as hooks, builders, etc. Those are used by plugins to experiment, and if some plugins are very popular, they later inline them into core for a better setup experience.

• Somewhat related, some projects will also just add a third-party plugin to the default set of gems. For example, Rails will automatically bundle/setup some gems in your gemfile, which they recommend, but anyone can still disable them. And those gems aren't maintained by the rails team. Makes it easier to switch them out later, if they are no longer relevant (technology has moved on, or such).