Automatic hyphenation doesn’t work in Chrome Android, ChromeOS, Linux, and Windows

[JayPanoz]

While I can get hyphens: auto to work in Chrome Desktop, we just can’t get it to work in Chrome Mobile (including Web Views).

Here’s what you can get on Desktop:

On mobile, it just won’t happen…

Even in landscape…

Tried changing the lang attribute from en to en-US to check if their mapping is super strict, to no effect.

Checked other ebook apps, and got the same result: no hyphens.

It kinda drives me crazy as it is supposed to be supported in Chrome only on Android and Mac…

Links:

• Chrome’s intent to ship
• Chromium bugs
• CanIUse

[JayPanoz]

So yeah, it seems it doesn’t work in Android.

The only manual test they’ve made is checking this link from a bug report to make sure it doesn’t crash Chrome Mobile…

And here’s what I could get:

On a related note, hyphens aren’t implemented on Windows, Linux ChromeOS yet.

So, question: do we want to just remove the setting from the non-iOS apps until they fix those issues?

We manage that automatically when the text-align is set so should those issues be fixed, we’ll at least have that automatic handling.

[JayPanoz]

Bug reported. Here is the related Chromium issue.

[JayPanoz]

Hyphen dicts available in Android 6.0.1 are:

• English American (en-US)
• Basque (eu)
• Hungarian (hu)
• Armenian (hy)
• Norwegian Bokmal (nb)
• Norwegian Nynorsk (nn)
• Sanskrit (sa)
• Pan Ethiopian (und-ethi)

They’re available in system/usr/hyphen-data (and accessible with apps such as ES File Explorer). It would be a good idea to list the dicts available for each version.

[laudrain]

Nothing for French !

[JayPanoz]

Yeah, cc-ing @HadrienGardeur since we talked about that a few months ago and wondered whether we should embed ours.

But if we can’t get Chrome to hyphenate in the first place…

[JayPanoz]

Dicts can be found there for the current version of Android.

And aliases can be found there.

[JayPanoz]

Given this issue impacts Electron as well on non-MacOS platforms, we’d better discuss it during the next call. cc @llemeurfr

Adding support would mean polyfilling this e.g. Hyphenator.js

[llemeurfr]

So if I try to summarize, hyphenation support by a rendering engine depends on the platform, the language (dict or no dict). Polyfilling is doable, but the system should be smart enough to avoid loading the js if hyphenation is natively supported.

I'll add that dyslexic user can't read with hyphenation on, therefore disabling hyphenation should be a user setting (advanced) and it should be disabled on some of the themes we'll provide.

[JayPanoz]

So yes, in anticipation of the call, a recap:

1. No support at all
   • hyphenation isn’t enabled at all;
   • you’ll end with huge gaps between words if the author/user justifies text.
2. Partial support
   • only the values none and manual are supported;
   • manual is what polyfills leverage, by inserting the ­ character (soft-hyphen, which is invisible) all over the place, in every word applicable;
   • this is Chrome on Windows, Linux, and ChromeOS.
3. Complete support
   • the value auto is supported in addition to none and manual;
   • quality depends on dictionaries available on the platform;
   • if a dict is not available, rendering engine may either fall back to english dict or complete disabling.

I know of early experiments to insert ­ characters in EPUB files to make it work anywhere but this can’t really scale well in production so they were short-lived. Now, it means that if authors justify text, we’ll have large gaps between words which, as you mentioned, hurts a11y. That should be solved by aligning text left though.

The biggest issue is an UX one i.e. having a setting which does nothing because automatic hyphenation is not supported.

Reference: canIuse

[JayPanoz]

Also, after taking a quick look at hyphenator.js issues, I’d rather not recommend polyfilling it whenever possible, as it might create extra issues e.g. performance issues (all words have to be checked in the DOM and modified when a pattern is applicable) and a11y issues (screen readers have a hard time managing soft hyphens).

On a related note, implementers willing to support hyphenation in MS browsers will probably have to check stylesheets for -ms-hyphens and add it if it can’t be found (same issue as vertical writing i.e. filling the gaps for bad authoring practices).

[JayPanoz]

So the current version of Android embeds hyphenation dicts for…

• Assamese (as)
• Bulgarian (bg)
• Bengali (bn)
• Church Slavonic (cu)
• Welsh (cy)
• Danish (da)
• German (de)
• UK English (en-GB)
• American English (en-US)
• Spanish (es)
• Estonian (et)
• Pan-Ethiopic (und-ethi)
• Basque (eu)
• French (fr)
• Irish (ga)
• Gujarati (gu)
• Hindi (hi)
• Croatian (hr)
• Hungarian (hu)
• Armenian (hy)
• Kannada (kn)
• Malayalam (ml)
• Mongolian in the Cyrillic script (mn-Cyrl)
• Marathi (mr)
• Norwegian Bokmal (nb)
• Norwegian Nynorsk (nn)
• Oriya (or)
• Panjabi (pa)
• Portuguese (pt)
• Sanskrit (sa)
• Slovenian (sl)
• Tamil (ta)
• Telugu (te)
• Turkmen (tk)

All seems to be retrieved from TeX (LaTeX patterns, hyphenation.org).

[JayPanoz]

So, the good news is that a fix is on its way for Chrome Android: https://chromium-review.googlesource.com/c/chromium/src/+/927931

[JayPanoz]

As a recap of our discussion about the global issue during yesterday’s call…

• We can’t embed hyphenation dictionaries easily, since @hyphenate-resource has been removed from the CSS Text specification and was only implemented by an HTML2Print software
• We therefore have to rely on system dictionaries so, on Android, it means the user almost have to change its device to get more dictionaries (because system updates…)
• Polyfilling via JS is too costly, and is likely to create dev complications, performance, and accessibility issues (some screen readers cut the word where the soft-hyphen is and one word may become two or three)
• We consequently have to rely on browsers because both options are non-starters
• We will lobby for hyphens and dictionaries but can’t realistically do much more

There’s hope though, as the Chrome Android issue has been tackled within 24 hours, is currently being patched, helped discover other issues and even improve i18n hyphenation – it also proves one tiny R2 demo can go a loooong way.

So as soon as Chromium is able to fix the Windows issue (they’re relying on Microsoft it seems), things could go pretty fast.