bug: Adds whitespace to <wbr>

[TheJaredWilcurt]

When using <wbr /> to indicate a potential line break location for text flow, Work Sans treats this zero-width element as though it has width.

Reproduction:

• https://jsfiddle.net/r2tmp5ds/

You can click on the middle option to toggle whether the <wbr> is applied. When <wbr> has display: none it no longer functions as an indication for line break opportunities.

This issue does not occur in other fonts, from my testing. This can cause visual noise when toggling strings of text from having <wbr> to not having them.

[weiweihuanghuang]

Thanks for bringing this to my attention! The reason why it's happening is because there's kerning between /c (slash and c), so when <wbr /> is added, it breaks the kerning... If you check the fonts, the actual wbr character (U+200B) has no width.

This is a tricky one to be honest, you'll find this in other fonts too if you add a wbr character anywhere where there's normally kerning.

[TheJaredWilcurt]

Is there a way to combine WBR with the characters on both sides, like you would with f and i in a ligature?

[weiweihuanghuang]

Not as a ligature but you could apply contextual kerning involving more than 2 glyphs. So technically in a way, but it would not make sense to do so performance wise.

What's the use case where you need to toggle WBR on and off?

[TheJaredWilcurt]

The file header has the name of the file path in full when the file is expanded, but is truncated when the file is collapsed.

[weiweihuanghuang]

But why is the toggling of the WBR necessary for truncating and collapsing the text?

[TheJaredWilcurt]

It's the other way. When truncated I remove <wbr> so everything can be on one line. Including the icon in the middle of the line indicating a rename.

When it is expanded I show the entire filename text, and add in <wbr>/<wbr> around the slashes in the filename to improve readability with better line break opportunities.