Emoji: treat the picker, support detection, and fallback rendering as one system

[Jiwoon-Kim]

The problem

While planning reactions for Notes, #75144 found no existing emoji picker component in Gutenberg. The gap is wider than the picker: WordPress has no shared emoji system. It handles emoji in three places that were built at different times and do not share a model:

1. Input. There is no reusable emoji picker in the editor today. A character map was requested in Reimplement character map #1678 (2017), and an emoji button in Core Trac #49885 (2020, closed as wontfix because operating systems ship their own). Notes reactions are adding one now: Add emoji reactions as a first class comment type #75144, Add emoji reactions (limited set on notes) #76767, and the full searchable picker in Notes: Open a full searchable emoji picker from the add-reaction button (stacked on #76767) #78176, which lives in packages/editor/src/components/collab-sidebar/.
2. Support detection. wp-emoji-loader.js runs two tests on a canvas: flag (the transgender flag, the Sark flag, and the England flag; any failure fails it) and emoji (the centre pixel of U+1FAC8). The result becomes everything or everythingExceptFlag. It runs on the front end only; the block editor does not load it.
3. Fallback. When a test fails, wp-emoji.js replaces emoji text with images from s.w.org. Core Trac #44001 and wordpress-develop#12252 discuss serving those images locally.

Because the three parts do not know about each other, a small mistake in one changes what every site shows, and the picker has to choose its data and storage format without a shared answer to "which sequences does WordPress treat as emoji, and which can this browser draw?". Things I reproduced or read in the source while building a plugin across all three:

• Core Trac #66104: the Emoji 17 test string is malformed, so emoji is always false and every emoji is replaced by an image, including in browsers that draw Emoji 17 (fixed in trunk for 7.2 in changeset 63755).
• When flag fails and emoji passes, only regional-indicator pairs and the rainbow and pirate flags are replaced. Two of the flags the flag test draws are not on that list: England (with Scotland and Wales, a tag sequence) stays as a plain black flag, and the transgender flag, a ZWJ sequence, is left as well. That is Core Trac #63451. It likely stopped reproducing because the emoji test began to fail (Emoji 16 in 6.8.2, then Core Trac #66104), which makes WordPress replace everything. With the Core Trac #66104 patch applied, a local test page in Chromium on Windows left the England flag unreplaced again.
• .wp-exclude-emoji is skipped only when it is below the element being parsed. If the excluded element is itself inserted later, or its own text changes, it becomes the parse root and its emoji are replaced. A follow-up to Core Trac #52219, now Core Trac #66120.
• The emoji test checks a single code point. A system that draws U+1FAC8 but not the new Emoji 17 ZWJ sequences counts as supporting Emoji 17.
• Smaller findings from the same work: the detection cache expires after about ten minutes rather than the week Core Trac #58663 assumes, and WP_Font_Face drops a font src that carries a query string such as ?ver= (Core Trac #66119).

What I'd like to discuss

Not a plugin to merge. I'd like to discuss where the boundaries should be, using a working implementation as a reference:

Layer	Question
Data	One emoji list (RGI sequences, names, groups) that both the picker and rendering can use.
Picker	Whether the picker from #78176 becomes a shared component for rich text, comments, and reactions, not only Notes.
Detection	Results per kind of sequence (country flags, subdivision flags, single code points, ZWJ and skin-tone sequences) instead of two booleans, available to scripts that need them.
Fallback	An ordered chain: the browser's own font, then a color emoji font, then images. A font keeps the emoji as text, so copying, search, and screen readers see the characters.

Working reference: Axismundi Emoji 0.3.1

Axismundi Emoji is in the Plugin Directory, and its Live Preview installs it and opens a demo page:

Open the Live Preview

The page lists 11 Unicode sequences and the two bundled custom emoji and, after load, says what drew each row: the browser's font, the bundled font, a WordPress.org image, or the site's own image. A panel shows the plugin's mode and WordPress's own test results. In Chromium on Windows with the latest WordPress, WordPress reported flag: no, emoji: no (Core Trac #66104); the plugin drew the three flags with its font and the other eight became images.

What the plugin does:

• Detection per profile: Core's flag probe is split into a country-flag profile and a subdivision-flag profile, each probed on its own canvas. A third profile, all RGI emoji, applies only when a site chooses the complete font. Results are cached with a version tied to the font files.
• Two self-hosted font files, both Noto Color Emoji (COLRv1, SIL OFL): a flags subset of 262 country and subdivision sequences for the two flag profiles, and the complete font for the third. Wrapped text carries WordPress's own .wp-exclude-emoji, so WordPress does not replace it as well.
• Automatic mode wraps only the flag profiles this browser cannot draw and uses the flags subset; everything else is left to the browser and to WordPress.
• Complete-font mode wraps every RGI emoji and draws it with the complete font, whatever the browser can draw.
• When the font cannot be drawn (its own probe fails), the wrapper is removed. The text then goes to WordPress's image fallback if that is enabled, and otherwise stays as text.
• Settings: the two modes above or WordPress's fallback only, and whether WordPress's detection script and image fallback load at all.
• Font Library: the font is offered as a collection.
• Custom emoji: the site's own images, written as :shortcode: and rendered in posts and comments, and declared as FEP-9098 Emoji tags when a federation plugin is present.
• Editor picker: Unicode 17.0 RGI emoji and the site's custom emoji in one searchable picker with collapsible groups that load on demand. The editor has no detection script, so the picker runs the probes without touching the editor's DOM.

Sizes, for the local-assets discussion in Core Trac #44001: the complete font covers all 3,944 RGI emoji in one 1.88 MiB WOFF2 file; the flags subset covers 262 flags in 699 KiB. Twemoji 17.0.2 is 4,009 PNG plus 4,009 SVG files, about 13.7 MiB together. With the complete font chosen and WordPress's image fallback switched off, the demo page made no requests to s.w.org and its HTML did not mention it: one font file drew all 11 Unicode rows.

Reactions. The companion Axismundi Activities plugin (not part of the demo) has emoji reactions that federate as FEP-c0e0 (EmojiReact, and Like with content), and its reaction picker reads the same catalogue from the Emoji plugin. Its key rule matches the one #78176 arrived at: only U+FE0E and U+FE0F are removed, so skin tones, ZWJ sequences, and flags stay distinct (unicode:U+1F44D there, 1f44d in Notes). Two things federation adds:

• A custom-emoji reaction is keyed by the authority that declared it (custom:example.com:blobcat), because two servers can ship the same shortcode. A shortcode that arrives without its Emoji declaration is not accepted as a reaction.
• One person may send several reactions to the same object, since FEP-c0e0 allows it and some servers send them.

Notes stores curated slugs and hex keys in comment_content of a reaction comment, while Core Trac #64638 registers comment meta for the earlier design, so the storage format is still open. It may be worth settling a key that local reactions, federated reactions, and custom emoji can share before it lands in Core.

Where #78176 is ahead: arrow-key navigation over the grid, a skin-tone selector (this plugin leaves skin-tone variants out of the grid), announced search results, translated emoji names, and ordering by frequency. This plugin is not meant to replace that picker; it shows the layers below it.

Known costs of the font approach: the download (the flags subset in automatic mode, the full font only when a site chooses it), a brief swap from the system font while the font loads, and it depends on the browser drawing COLRv1, which is why the plugin probes the font and steps aside when it cannot.

Questions

1. Should the Notes picker become a reusable component, and where should its emoji data live so rendering can use the same list?
2. Should detection report per kind of sequence rather than flag and emoji?
3. Could a Font Library family declare that it is an emoji font (see Allow Font Library font families to declare their intended use #82848), so that detection prefers it before images?
4. Should the reaction key in Notes leave room for custom emoji with an authority, so the same key works for reactions that arrive from other sites?

Related

• Gutenberg: Reimplement character map #1678, Add emoji reactions as a first class comment type #75144, Add emoji reactions (limited set on notes) #76767, Notes: Open a full searchable emoji picker from the add-reaction button (stacked on #76767) #78176, Allow Font Library font families to declare their intended use #82848
• Core Trac: #44001, #49885, #52219, #58663, #63451, #64638, #66104, #66119, #66120
• wordpress-develop: #12252