undefined

points

[-]

That's new

> For example, U+200B ZERO WIDTH SPACE was originally classified as a space character (General_Category=Zs), but it was reclassified as a Format character (General_Category=Cf) to clearly distinguish it from space characters in its function as a format control for line breaking.

by nickcw16 hours ago|

prev|

[-]

Ha! Yes I discovered that this is true in C as part of my IOCCC entry:

https://github.com/ioccc-src/winner/blob/master/2025/ncw3/pr...

by gucci-on-fleek8 hours ago|

prev|

[-]

Braille Pattern Blank "⠀" (U+2800) is another one of my favourites, since it's also not considered whitespace, but it looks like it. It can actually be fairly helpful for forms that won't let you leave any field blank, since it bypasses most whitespace checks.

by eviks3 hours ago|

parent|

[-]

Indeed, the ossification of this old absurdity can be helpful, also for visual alignment within names.

This prompted me to finally dig a bit and find the official reference why they didn't fix the bug despite a plea from some Braille council

https://www.unicode.org/L2/L2025/25183-utc184-properties-rec...

by networked43 minutes ago|

parent|

[-]

> It was found that many publications that use Unicode Braille characters use U+2800 with a marking glyph. A marking space is not without precedent, consider U+1680 OGHAM SPACE MARK. However, in some cases, U+2800 is clearly used as a symbol, to indicate the presence of a space when describing a Braille sequence corresponding to a symbol or punctuation, similar to the use of ␣ (U+2423 OPEN BOX) to indicate the presence of a space. Especially in cases where it is used in a trailing position, as in the [UNE13] example, it is clear that it would be inappropriate for this symbol to disappear.

> Considering this usage as a marking symbol, together with concerns about changing the relatively stable—and often hardcoded—White_Space property (a property of only 25 code points, last changed in Unicode 6.3, when U+180E MONGOLIAN VOWEL SEPARATOR ceased to be a space), the PAG preferred a more targeted change.

This doesn't seem that unreasonable.

by Rendello16 hours ago|

prev|

[-]

I use it for sites like Facebook where I want to type :) without it changing to the terrible `U+1F642 SLIGHTLY SMILING FACE` [1]. I wouldn't really mind if it were the `U+1F60A SMILING FACE WITH SMILING EYES` [2], but the first one is so laughably terrible, as if I'd really want to send an emoji to communicate a disingenuous, pained smile as a default. Some platforms let you backslash-escape sequences so they don't get turned to emoji, like \:), but for Facebook and the like, putting a ZWS in between the letters stops the conversion.

Though if your emoji is at the end of a line, it'll potentially break your emoji between the two lines. since That's what a ZWS is for, after all.

1. https://util.unicode.org/UnicodeJsps/character.jsp?a=%F0%9F%...

2. https://util.unicode.org/UnicodeJsps/character.jsp?a=1F60A&B...

by Y_Y2 hours ago|

parent|

[-]

I look like U+1F642 when I smile genuinely

by Aozora715 hours ago|

parent|

prev|

[-]

My favorite use for it is putting it into mandatory surname fields, which sometimes works.

by Timwi13 hours ago|

parent|

prev|

[-]

Try using the zero-width non-joiner instead (U+200C).

by TacticalCoder21 hours ago|

prev|

[-]

> My favorite unicode character is zero width space. One of its funniest properties is that it's not a whitespace.

My editor is configured to never show any character (except the one and proper newline) at less than the full-width of a regular character (in the monospace font I'm using ofc).

And if it's not a visible ASCII char, not only it's always shown at least at full-width, it's also shown as bold magenta on a black background. As the non visibe zero-width is empty, it shows as full-width on a black background.

Sticks out like a sore thumb.

by MadnessASAP15 hours ago|

parent|

[-]

Would you mind sharing your editor and magic recipe?

by Cpoll17 hours ago|

prev|

[-]

[dead]