[css-text] Need additional value of word-break for Korean

[frivoal]

In regular situations, word-break: normal is expected to pick the right kind of word breaking for various scripts, keeping letters of a word together in languages that have word-based line breaking, while allowing wraps in the between letters of a word in languages where that's the normal behavior.

However, Korean typography has been evolving, and while the normal values corresponds to what used to be normal (allowing wraps in the middle of words), and needs to continue to have this behavior for compat reasons, the preferred behavior is increasingly the one achieved by keep-all.

In a document that where all parts are properly language tagged, * { word-break: normal; } lang(ko) { word-break: keep-all; } achieves the desired behavior.

However, this is not quite enough to solve the problem in the case of documents with user-generated content: when a user types content in a textarea, or a contenteditable (of if user generated content is retrieved from a database), the author of the page does not generally know what the language is, and cannot tag it in the markup. The following options are available to them, none of them great:

• use word-break: normal on elements accepting user input: This will do "the right thing" for all languages, except for that style of Korean, which will break too often.
• use word-break: keep-all on elements accepting user input: this will do "the right thing" for space separated languages, including that style of Korean, but will badly break languages like Japanese or Chinese, by disabling wrapping opportunities and causing potential overflow.
• use word-break: normal on elements accepting user input, but also add a piece of javascript that monitors the content for changes, and switches the whole element to work-break: keep-all if any hangul text is detected:
  • This breaks if the content input by the user contains a mixture of Korean and languages like Japanese or Chinese, as it would apply keep-all to them as well.
  • This isn't a purely declarative solution, so it fail if Javascript is disabled
• Use * { word-break: normal; } lang(ko) { word-break: keep-all; } together with a piece of Javascript that adds the lang=ko attribute (and creates spans/divs as necessary to apply it) on the parts of the text input by the user that contain hangul, and lang="" (or lang=somethingelse, if the somethingelse can be detected reliably) on parts that don't:
  • Getting this script right is very difficult. Not merely because of how it must analyse the content and adjust the markup accordingly, but also because of how it would need to integrate with editing operations: how to make these DOM modifications inside a content editable in a way that is compatible with the browser's undo stack? How to make them in a way that doesn't interfere with ongoing IME operations? How to make them in a way that is compatible with the hodge podge of markup that different browsers may generate inside a contenteditable element? etc
  • Getting this script to be correct AND performant is even harder. But performance is important: not all user input is tweet-sized. Think for instance of an online document editor, which may contain multiple pages of (multilingual) rich text.
  • This isn't a purely declarative solution, so it fail if Javascript is disabled

So, to solve this, I propose that we add a keep-all-hangul value (or just keep-hangul), that behaves the same as keep-all for the unicode characters that correspond to hangul, and normal for everything else.

[Crissov]

Sounds like auto to me.

[frivoal]

Well, we already have an "auto" value, which is actually called normal on this particular property. I don't think having both auto and normal would be very understandable. the new values is effectively "normal-for-most-things-but-keep-all-for-hangul", so I'm shortening that to "keep-all-hangul", keeping only the way this value is different from normal in its name.

[kojiishi]

Does it work for Hangul/Hanja mixed-content? cc @jungshik

[tabatkins]

Is there a reason to give Korean a special value here, versus just changing the behavior of "normal" to better reflect current Korean writing practice?

[frivoal]

@kojiishi

Does it work for Hangul/Hanja mixed-content?

Depends what you mean by work. It would break between the Hanja, and not between the Hangul. This is not the ideal behavior, which would also keep Hanja of a single word together, but:

• Hangul/Hanja mixed content is increasingly rare, and even when mixed, the Hanja are few.
• In cases where the language is not tagged, we cannot know (without using heuristics on the whole content) if we have a case of Korean with mixed hangul/hanja, or a case of multilingual text with Korean mixed with Japanese or Chinese. And if it is the later, disallowing breaks within Hanja/Hanzi/Kanji words would be problematic, as we could end up with long strings of Japanese/Chinese text with no breaks at all.
• In cases where the language is tagged, it is possible to use a lang(ko) selector to apply the keep-all value.

---

@tabatkins

Is there a reason to give Korean a special value here, versus just changing the behavior of "normal" to better reflect current Korean writing practice?

Korean writing/typography culture is undergoing a transition. The keep-all style is increasingly common, but not universal (yet). There are authors who do continue to expect the current normal behavior, and might not be too happy if it changed.

Also, it is likely (I don't have data, but it is logically probable) that there are websites out there that would break if we changed the default:

• sites with tightly sized elements, such as menus, buttons, etc, where the content wouldn't fit if line-breaking happened differently
• old/traditional text didn't even have spaces at all. Even among authors who do not prefer the keep-all behavior, the modern practice is to put spaces between words. But pages containing older text may not have spaces, and a keep-all type of behavior on these would suppress all/most line breaking opportunities, which would be bad.

[jihyerish]

I'm curious about the reason for separating Korean from Chinese and Japanese.

For my experience, in the text editor or web page for Korean break-all is the default result.
I think this is because Hangul is a syllable language and also frequently used Korean words consist of relatively few characters.

[frivoal]

@jihyerish The reason why some people want that behavior, is that Korean (nowadays) uses spaces between words, but Chinese and Japanese don't. Breaking words the same in all 3 languages is the traditional way to do things, and should continue to exist (and to be the default). However, since Korean does have spaces, doing line breaking in Korean the same as in English is also something (some) people want.

[jungshik]

@frivoal I don't think that 'keep-all' is increasingly common. Neither do I buy your reasoning that putting inter-word space is the cause for preferring to have 'keep-all'.

The vast majority of Korean text in books, newspapers, magazines (when the correct typographic standard is adopted) have 'break-all' period. Some ill-typeset documents (especially in 1990's made by poorly i18n'ized DTP software) may use 'keep-all', but that's an aberration !!

Modern Korean orthography always dictates the use of inter-word space (over 80 years at minimum). Yet, breaking at the syllable boundary has been the norm for paragraphs.

Let me tell you what Korean web authors did in mid-1990's when Netscape 1.x didn't do the right thing with Korean line breaking. They wrote a script to insert <wbr> between every syllable pairs to let Netscape 1.x know that there IS a line breaking opportunity at each and every syllable boundary.

keep-all does have its use. keep-all is preferred for Korean when the corresponding English text does NOT want hyphenation. That is, multi-line titles (song, movie, book, article), multi-line ad copies, etc.

However, they're exceptions rather than norm.

Changing 'word-break: normal' behave like 'word-break: keep-all' for Korean is akin to winding the clock back to 1994 (Netscape 1.x behavior).