why the trans flag emoji is the 5-codepoint sequence it is
90 points by heckie
90 points by heckie
The background animation on the page is neat, but I find it distracting to the point of being unable to concentrate on the text. Is there a way to turn it off?
Firefox's reader mode worked well for me.
Except that footnotes look weird, with the number being in its own paragraph.
unfortunate shortcoming with zola's footnote rendering; it's honestly my only complaint about it as a static site generator. i assume one day its pulldown-cmark integration will get a bit more polish, or that the lack of backlinks at the end of footnotes will eventually get me to polish it off
In my case I created some shortcodes that can replace the builtin footnotes. It's a pain to write, but at least the outcome looks better.
Disabling javascript will disable the particle background; you can also block the particle.js.
I'll add a nav button to toggle the background effects the next time I touch the site - I try to make the aesthetic not get in the way of usability, and it'd fit well alongside the theme & font toggles.
Text browsers like lynx should also work fine (I don't personally endorse text browsers though)
A better option would be to respect the prefers-reduced-motion media query, that way people do not have to manually toggle anything.
That's fine as a default, but you need a separate toggle too. I may want to keep the animation when switching spaces in macOS, and want various other animations which are triggered by interaction, but not want the background of a website to be in constant motion.
viewing the page without js fails the anubis challenge however.
there's a particles toggle button (w/ localstorage persistence) in the nav header now, and I also made the text-content backdrops more opaque so that the particles behind them are less distracting. You can turn the particles off now :)
Oddly enough, I didn't even notice it on mobile, when I looked this morning. On desktop I find it quite distracting.
U+1F3F3 is the only 2-byte codepoint in 🏳️⚧️, so it takes 6 bytes to represent correctly, while being 5 codepoints, and rendering as one glyph.
In UTF-8, the trans flag is 4+3+3+3+3 bytes = 16 bytes. IMHO, there is a confusion with UTF-16 here. In UTF-16, the trans flag takes six UTF-16 code units (12 bytes). I've emailed the author.
yeah, I dunno why I thought every codepoint I listed was one byte, when I mentioned in one of the footnotes that ASCII chars are the only single-byte codepoints. I'll update that in a bit - not a confusion with utf-16; I just got sidetracked and thought a 2-byte codepoint was one byte, somehow.
Pet peeve: on iOS, WhatsApp uses the system emoji font for every character except 🏳⚧, which is rendered using the WhatsApp emoji font. Presumably this was because WhatsApp implemented it before Apple did, but they never bothered to remove the special case, so we're stuck with sequences like 🏳️🌈🏳⚧🏳️🌈🏳⚧🏳️🌈 looking terrible because the trans flag is a slightly different shape from the pride flag (and indeed every other flag emoji).
100% this is legacy from the initial implemention approach (and also because all of the trans people remotely involved with this, were no longer at facebook by the time the trans flag emoji proposal was approved and added to the spec :&)
Interestingly, per this page, there are 594 other glyphs that use 5 codepoints. Neat!
Too bad the proposal to add individual skin tone customisation for the family emojis (1-2 parents, 1-2 kids) was never accepted. Those would have set unassailable length records.
And you can easily inspect the underlying code points of emoji in your browser's JS console:
Array.from("🧑🏿❤️💋🧑🏾") // break up into array of code points
// Array(10) [ "🧑", "🏿", "", "❤", "️", "", "💋", "", "🧑", "🏾" ]
Array.from("🧑🏿❤️💋🧑🏾") // code point value of each character
.map(char => char.codePointAt(0))
// Array(10) [ 129489, 127999, 8205, 10084, 65039, 8205, 128139, 8205, 129489, 127998 ]
Array.from("🧑🏿❤️💋🧑🏾") // characters in unicode code point notation
.map(char => char.codePointAt(0))
.map(codePoint => codePoint.toString(16))
.map(hex => `U+${hex.toUpperCase()}`)
// Array(10) [ "U+1F9D1", "U+1F3FF", "U+200D", "U+2764", "U+FE0F", "U+200D", "U+1F48B", "U+200D", "U+1F9D1", "U+1F3FE" ]
pretty similarly in python:
for c in '🏳️⚧️':
print(hex(ord(c)), end=' ')
# 0x1f3f3 0xfe0f 0x200d 0x26a7 0xfe0f
python's ord kinda feels like a relic builtin, at this point, though.
python's ord kinda feels like a relic builtin, at this point, though.
Yeah, but please don't say that too loudly! When it's useful, it's very, very useful. I don't want anyone to hear it's a relic and get rid of it :)
Heinous website, I use my mouse cursor to highlight the parts I want to read and this makes the content impossible to read.
Is this in light mode or dark mode? The light mode look is probably best without JavaScript or reader mode; the site is meant for dark mode on an oled panel because I suffer light sensitivity issues. I don't really test that theme much because it is actively painful for me to test; it's there because I've simply been asked for a light mode toggle.
I don't have access to the dark mode on Firefox 146. See this screen recording: https://imgur.com/a/XCAiSJU
The offending css selector that was breaking that has been summarily dismissed - I never tested site functionality in a browser with a light color scheme preference. Please give it another whirl; the site should properly default to dark mode for proper readability / contrast now.
I'll still do another pass later today to make the particles.js respect the reduced motion media query. Thanks for the feedback :)
If you don't use nor test the light color scheme, why do you even have it? It would be better for everyone involved if you had just one scheme that works well enough, instead of two where one is much worse than the other.
I do use it more in the summer, and I added the light theme after a friend asked me for a light mode toggle.
It is primarily intended for the gallery side of the site, where toggling the backdrop/lightbox color is much more meaningful. I have a backlog of art with transparency to finish tagging => processing into the site; the blog and its readability is just one of the angles here.
I'll keep iterating on it - I just also don't get why some of the feedback in this direction feels rather pointed when there's two whole posts. It has not received widespread feedback until now.
Hm, that doesn't happen for me, in either light or dark mode. Highlighting completely hides the funny little background stuff and gives the white text on blue that's typical of highlighting.
This is my experience with the website: https://imgur.com/a/FhqfJfn . It plays very badly with my eyes and my brain, unfortunately. My eyes and brain are solicited constantly while trying to read static text.
it's true that most fonts (apple emoji, twemoji, noto) will work with the three-codepoint non-RGI sequence though (1f3f3, 200d, 26a7) ^-^ if you're ever byte-shaving
Yep! A large part of this is because the spec around emoji sequences has changed in the past few years.
A small part of the 5-codepoint Correctness in 2018 was due to how copy & pasting would work on various systems with ZWJ sequences that didn't have single glyph mappings - some platforms would only copy the white flag, and would consider the ZWJ and following codepoints to be another grapheme because the 26A7 was text mode
the representation can be (and should be!) a lot leaner now, but I wanted to nail down in writing that at a point in history, we had to be wholly technically correct at that moment in time to achieve inclusion, since it's really easy to overlook those details as time goes on.
On my system only Chrome 143 supports the 3-codepoint sequence. Both Firefox Nightly and Epiphany 49 display two text-mode glyphs.
Hmm, it works on the latter browsers if I change the style to font-family: monofur,sans-serif,emoji.
Is this perhaps a FontConfig issue?
firefox renders the 3-codepoint correctly on macos and linux for me, but this is also why I couched my claim as "it likely displays correctly now" - I know deep down in my heart that emoji rendering will always be a hack.