What surprises me is that some engines support different Unicode versions per feature. Check out Safari for example that has Unicode v12 support for Identifiers, but Unicode v11 for RegExp property escapes.
<css-doodle /> is a web component for drawing patterns with CSS.
The component will generate a grid of divs by the rules (plain CSS) inside it. You can easily manipulate those cells using CSS to come up with a graphic pattern or an animated graph. The limit is the limit of CSS itself.
Combine <css-doodle /> with generated content and Unicode characters, and you can create nice decorative patterns as shown above.
At Small Town Heroes I’m currently working on a newsreader app built using React Native. On Android (even 7.1.1) we noticed this weird issue where some emojis would render incorrectly when we were applying styling on it using index-based ranges: the range seemed to be off by one, splitting the emoji into its separate bytes. What made this issue even more weird is that this behaviour stopped when we connected the app to a debugging session.
Figure: Result of applying a specific style on this 41 symbol counting sentence.
>> 'Emoji 🤖'.length
To get the correct symbol count, you can use Array.from() or the spread operator(*):
(*) Do note that this technique is not 100% bulletproof though. It has “problems” with skin tone modifiers and other emoji combinations – which in itself yields some fun results – but let’s ignore that for now.
Knowing how to get the correct count, it’s possible to extract proper substrings from that sentence, to apply your styling on (*):
// Wrong way to do it (not multibyte-aware)
>> 'Emoji 🤖'.substr(0,7);
// Correct way to do it (multibyte-aware)
>> [...'Emoji 🤖'].slice(0,7).join('');
(*) Why not just use String#length and String#split all throughout our code (thus bypassing the whole thing) you might wonder? Well, the editor used to input the article *is* multibyte aware, so it would return 7 as the length of that sentence 😉
Now, even though we were using Array.from() to get the correct substrings, we ran into issues on Android whilst doing so: it would aways yield "Emoji �", no matter which technique we used. Long story short: we found out that the runtime on the Android phone – somehow – was using a non-multibyte aware Array.from(), explaining the wrong result.
The solution to bypassing this mysterious problem was to use runes, a library that's Unicode-aware. Above that it also plays nice with skin tone modifiers and other emoji combinations, making it superior to the Array.from() technique.
When visiting a domain name containing a Unicode character that visually resembles an ASCII character, your browser will transform the Unicode characters to Punycode in the address bar to prevent homograph attacks.
For example: the Cyrillic а (codepoint U+0430) totally looks like the Latin a (codepoint U+0061). When visting brаm.us (with the Cyrillic а in place of the Latin a), your browser will transform the URL to xn--brm-7cd.us
Turns out this is not always the case though:
Chrome’s (and Firefox’s) homograph protection mechanism unfortunately fails if every characters is replaced with a similar character from a single foreign language. The domain “аррӏе.com”, registered as “xn--80ak6aa92e.com”, bypasses the filter by only using Cyrillic characters.
TIP: Whenever you’re in doubt when receiving a mail from a “well known party” containing a link, I recommend manually typing the URL into the address bar.