This was my second Chrome extension. It started with a general distaste for the yellow \"neutral\" emoji skin tone. As someone who watched The Simpsons a lot growing up, I see the yellow skin tone as a white skin tone in a poor disguise. Sure yellow isn't actually white, and there is also a white skin tone emoji, but if you look at the characters in The Simpsons, there are no white characters and yet there are characters of color. Even if you disagree about yellow being another white option, you can't disagree that it's a way to opt-out of race, which I also think is unfortunate. Human skin tones are variable and can be celebrated instead of conveniently omitted. So, using Cloud to Butt as inspiration, I set to work.
\nIn practical terms, there are five different skin tones (based off the Fitpatrick scale) that can be applied to emoji to change them from yellow to a true skin tone (one of Fitz-1/2, Fitz-3, Fitz-4, Fitz-5, and Fitz-6). in technical terms, any emoji that is \"skin tone eligible\" has six separate glyphs, for each of the five skin tones and the yellow default presentation. Although a glyph in a typeface typically maps one-to-one with a unicode code point, a glyph can also represent a ligature. Unicode considers ligatures to be a matter of presentation and therefore outside of its jurisdiction. Therefore, any typeface can choose to make a ligature for any combination of letters. Some common pairs, for example, are fi, ff, and ae. This same technical implementation is used to implement skintones. So π πΏ is actually the ligature of π and πΏ. Which means that as soon as you place a skintone swatch character next to the Father Christmas emoji, it immediately becomes the skin tone variation of Father Christmas.
\nThis is important to understand, since the extension will have to make the correct text substitions to apply skin tones.
\nNot all emoji can have skin tones applied to them. This works: πΆ + πΌ = πΆπΌ. This does not work: π + πΌ = ππΌ. This makes intuitive sense, but the details need to be implemented somewhere. This is where the emoji-data.txt file comes in. It is the canonical source of what emoji can pair with what. The stanza of lines of say Emoji_Modifier_Base are the emoji or emoji ranges that support skin tones (and gender) modifiers. This is a format between machine readable and prose that I like to call \"machine attemptable\". Because why not, I wrote a python script to parse this into a JS const.
This way, the array of all emoji that are skin tone eligible is generated and embedded into the final extension content script.
\nAt this point it may seem like all that's left to do is write a regex to replace emoji that aren't followed by a skin tone with an emoji that has a skin tone. I thought this too, but there is a little thing called the Zero-width Joiner. Remember that ligatures happen when a typeface declares a combination of unicode code points should be replaced by a single glyph. As should be expected, life isn't this simple. Sometimes (in emoji and in some languages) it is valid to have two code points next to each other as either a combined glyph or as separate glyphs. Consider this family: π¨π©π¦π¦. Now consider the same family as a single glyph: π¨βπ©βπ¦βπ¦. The only difference here is in the single glyph example, a zero-width joiner (zwj) has been inserted between each family member. These intricate glyphs can also be decomposed quite elegantly with JavaScript:
\nconst intricateEmoji = 'π¨βπ©βπ¦βπ¦'\nconst allTheParts = [...intricateEmoji] // [ 'π¨', '<zwj>', 'π©', '<zwj>', 'π¦', '<zwj>', 'π¦' ]But what happens when we introduce skin tones? Can we make mixed-race families? The answer is yes: π¨π»βπ©πΏβπ¦πΎβπ¦π½. This is achieved by having nested skin tone ligatures within larger family ligatures. The full set of unicode code points is:
\nconst family = [\n \"π¨\", \"π»\", // Fitz-1/2 father\n \"β<zwj>\",\n \"π©\", \"πΏ\", // Fitz-6 mother\n \"β<zwj>\",\n \"π¦\", \"πΎ\", // Fitz-5 son\n \"β<zwj>\",\n \"π¦\", \"π½\" // Fitz-4 son\n]So this needs to be handled in the extension to make sure that if the original author of copy intended to have a family glyph, this extension doesn't come in and accidentally mangle it by injecting a skin tone where one isn't compatible
\nAt this point, all that was left to do was write the JS and regular expressions that actually did the text substitutions and call that code at the write time from within the Chrome extension. The write time to run the code is during the document_end content script hook, and the write regex is this unfortunate thing.
Add the extension from the Chrome web store π Emoji Skin Tone Randomizer.
\njavascript:<insert-lots-of-javascript-here>.\n"},{"project":"nomad-web-ui","url":"/images/nomad-ui-jobs.png","alt":"Nomad UI jobs list","caption":"The Jobs List page serves as the home page for developers interacting with Nomad. It represents all software known to the cluster.\n"},{"project":"nomad-web-ui","url":"/images/nomad-ui-deployments.png","alt":"Nomad UI job deployments","caption":"Nomad supports automatic rolling and green/blue deployments as well as optional canary deployments. All of this is represented in the UI\nand kept up to date in realtime.\n"},{"project":"nomad-web-ui","url":"/images/nomad-ui-logs.png","alt":"Nomad UI stdout log streaming","caption":"Nomad also has a streaming HTTP API for tailing logs for allocations. The UI lets any privileged user see these logs using fetch and streaming\nrequests when possible and falling back to polling otherwise.\n"},{"project":"nomad-web-ui","url":"/images/nomad-ui-stats.png","alt":"Nomad UI metrics over time","caption":"Stats in Nomad are not stored, but the UI makes a best effort attempt at tracking data over time by storing previous values in memory,\naccounting for skipped data, and persisting historical data (up to a limit) between page views.\n"}]}},"pageContext":{"slug":"/project/emoji-skin-tone-randomizer/"}},"staticQueryHashes":[]}