Broken Hyphens in Chromium 96: An Explanation (and Fix)

~

# The Bug

Here’s (a screenshot of) a Pen that has the font set to Arial and has hyphenation enabled:

(Click image to go to interactive Pen)

The hyphenation itself will work as expected, but for some reason — which we’ll detail below — it shows box characters where the hyphens should be.

The CSS powering the Pen are the 100 bytes of CSS to make any page look good, along with this little snippet:

body {
	font-family: arial;
	hyphens: auto;
}

The bug happens in Chromium-based browsers on Mac — That’s Google Chrome, Microsoft Edge, Brave, etc. It only happens on macOS Monterey; Big Sur does not show this bug.

~

# Digging Deeper

Searching around I found Chromium Bug #1267606 which covers the bug. In it, Chromium Engineer Dominik Röttsches (drott) dug deeper and unearthed the details.

There are two hyphen characters, U+2010 (HYPEN) and U+002D (HYPHEN-MINUS) […]

Our hyphenation code first looks for U+2010 in the font, otherwise uses U+002D.

Even though Arial has no U+2010 set, the Core Text API — which is used to retrieve the glyph — claims there is:

The new and old version of the font do not have hyphens in their cmap table, but the CoreText function for retrieving a glyph id does strangely return 16 for U+2010 on Monterey, but doesn’t find the glyph in the font on Big Sur (as it should).

And when a font tries to show a glyph it does not have, it’ll show a box instead.

~

# The workaround

The bug itself has already been patched, and the patch is included in Chromium 98 which is due Feb 1, 2022. If you can’t wait until then, there’s a CSS workaround that you can use: the hyphenate-character property

This property specifies the string that is shown between parts of hyphenated words.

For WebKit (which powers Safari) and Blink (which powers Chromium) you need to use the vendor-prefixed -webkit-hyphenate-character variant, so the CSS fix becomes this:

html {
    -webkit-hyphenate-character: '-';
}

Easy, peasy 🙂

~

~