Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
It is to do with the fact that you need a combiner unicode character that isn't supported in domain names.
I get the concept but don't know the right terms, but you combine two emojis with a special character [U+200D] to create the woman at computer or man at computer.
URLs don't support this invisible character (I think because of security) so as far as I am aware it is impossible to fix the issue on Outbound emails as technically my domain name is 👩💻👨💻 and it is just how unicode characters are decoded that allow me to have 👩💻👨💻 as the domain (as it decodes to the correct characters).
I have no idea if that is a good explanation but sadly I think it can't be fixed in any email client etc.
Ah I see. The first half makes sense, but the combining characters are themselves Unicode characters ([...'👩💻'].length === 3), so it's not just something in how Unicode itself is decoded. It must be something in the punycode spec that states that invisible characters are simply ignored. I just checked and it seems this is the case:
Edit: Actually, it might just be Chromium's implementation, rather than the spec itself. In Firefox, new URL('https://👩💻👨💻.to').href is xn--qq8hb0wb.to/, whereas new URL('https://👩💻👨💻.to').href is xn--1uga01807aca52bc.to/ (a domain name that doesn't resolve). Sure enough, opening 👩💻👨💻.to doesn't work in Firefox (but 👩💻👨💻.to works fine).
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Yeah it is something I should actually learn properly as the amount of times I get confused between &X2394; and U+212C etc. as ways of encoding emojis is quite embarrassing (as was that sentence probably as like I said, I don't understand it all properly 🤣)!
And punycode was the term I couldn't remember so thanks for that!
The combined emoji thing is most likely just a font thing in your email client. Most likely different email clients will display it differently.
It is to do with the fact that you need a combiner unicode character that isn't supported in domain names.
I get the concept but don't know the right terms, but you combine two emojis with a special character [U+200D] to create the woman at computer or man at computer.
URLs don't support this invisible character (I think because of security) so as far as I am aware it is impossible to fix the issue on Outbound emails as technically my domain name is 👩💻👨💻 and it is just how unicode characters are decoded that allow me to have 👩💻👨💻 as the domain (as it decodes to the correct characters).
I have no idea if that is a good explanation but sadly I think it can't be fixed in any email client etc.
Ah I see. The first half makes sense, but the combining characters are themselves Unicode characters (
[...'👩💻'].length === 3), so it's not just something in how Unicode itself is decoded. It must be something in the punycode spec that states that invisible characters are simply ignored. I just checked and it seems this is the case:Pretty interesting!
Edit: Actually, it might just be Chromium's implementation, rather than the spec itself. In Firefox,
new URL('https://👩💻👨💻.to').hrefis xn--qq8hb0wb.to/, whereasnew URL('https://👩💻👨💻.to').hrefis xn--1uga01807aca52bc.to/ (a domain name that doesn't resolve). Sure enough, opening 👩💻👨💻.to doesn't work in Firefox (but 👩💻👨💻.to works fine).Yeah it is something I should actually learn properly as the amount of times I get confused between &X2394; and U+212C etc. as ways of encoding emojis is quite embarrassing (as was that sentence probably as like I said, I don't understand it all properly 🤣)!
And punycode was the term I couldn't remember so thanks for that!
It will be converted to punycode, anyway.