What type of issue is this?
Incorrect support data.
What information was incorrect, unhelpful, or incomplete?
The Chrome support note for css.properties.word-break.auto-phrase currently says:
This value is only applicable if lang="ja" is specified. This value has no effect on other locales.
Chrome also applies distinct auto-phrase line-breaking behavior when the resolved content language is Korean (ko), so the note incorrectly describes Korean as unsupported.
What browsers does this problem apply to?
Chromium (Chrome, Edge 79+, Opera, Samsung Browser).
What did you expect to see?
The Chrome note should include both Japanese and Korean support. For example:
In Chrome, this value affects text whose content language resolves to Japanese (ja) or Korean (ko). Japanese uses an ML-based phrase-breaking engine, while Korean uses ICU's non-ML phrase-breaking path. For other locales, it behaves as normal.
Did you test this? If so, how?
I tested identical lang="ko" elements in Google Chrome 152.0.7977.65 on macOS 26.4.1, changing only word-break.
Test text:
<p lang="ko">더 나은 사용자 경험을 만드는 방법</p>
I scanned the element from 1 px through its max-content width and recorded each distinct first-line endpoint. The resulting breakable segments were:
word-break: normal
더 | 나 | 은 | 사 | 용 | 자 | 경 | 험 | 을 | 만 | 드 | 는 | 방 | 법
word-break: auto-phrase
더 | 나은 | 사용자 | 경험을 | 만드는 | 방법
Both probes used the same font and width, with overflow-wrap: normal and text-wrap: wrap.
I directly verified the runtime behavior in Chrome 152. I did not independently run Chrome 119. However, the ICU revision vendored by Chrome 119 already contains the source comment that phrase breaking supports both Japanese and Korean while the ML engine supports only Japanese.
Supporting implementation details
ICU's current CJK break-engine source explicitly states:
PhraseBreaking is supported in ja and ko; MlBreakEngine only supports ja.
This distinction is intentional: Korean phrase breaking is supported through ICU's non-ML path rather than being treated as an unsupported locale.
BudouX's Korean support documentation provides useful rationale for that implementation split. It explains that Korean generally uses spaces between words and recommends word-break: keep-all as a more performant way to prevent words from splitting across lines than installing an ML-based segmenter. In other words, Korean can use the boundaries already indicated by spaces for this common line-breaking goal, whereas Japanese benefits from an ML-based phrase-breaking engine.
References
Additional context
The Chrome launch article described Japanese support when the feature shipped and said that Korean and Chinese support were planned. The current BCD note appears to reflect that launch-time description, but it no longer matches Chrome's Korean behavior or the ICU implementation bundled by Chromium.
What type of issue is this?
Incorrect support data.
What information was incorrect, unhelpful, or incomplete?
The Chrome support note for
css.properties.word-break.auto-phrasecurrently says:Chrome also applies distinct
auto-phraseline-breaking behavior when the resolved content language is Korean (ko), so the note incorrectly describes Korean as unsupported.What browsers does this problem apply to?
Chromium (Chrome, Edge 79+, Opera, Samsung Browser).
What did you expect to see?
The Chrome note should include both Japanese and Korean support. For example:
Did you test this? If so, how?
I tested identical
lang="ko"elements in Google Chrome 152.0.7977.65 on macOS 26.4.1, changing onlyword-break.Test text:
I scanned the element from 1 px through its max-content width and recorded each distinct first-line endpoint. The resulting breakable segments were:
Both probes used the same font and width, with
overflow-wrap: normalandtext-wrap: wrap.I directly verified the runtime behavior in Chrome 152. I did not independently run Chrome 119. However, the ICU revision vendored by Chrome 119 already contains the source comment that phrase breaking supports both Japanese and Korean while the ML engine supports only Japanese.
Supporting implementation details
ICU's current CJK break-engine source explicitly states:
This distinction is intentional: Korean phrase breaking is supported through ICU's non-ML path rather than being treated as an unsupported locale.
BudouX's Korean support documentation provides useful rationale for that implementation split. It explains that Korean generally uses spaces between words and recommends
word-break: keep-allas a more performant way to prevent words from splitting across lines than installing an ML-based segmenter. In other words, Korean can use the boundaries already indicated by spaces for this common line-breaking goal, whereas Japanese benefits from an ML-based phrase-breaking engine.References
Additional context
The Chrome launch article described Japanese support when the feature shipped and said that Korean and Chinese support were planned. The current BCD note appears to reflect that launch-time description, but it no longer matches Chrome's Korean behavior or the ICU implementation bundled by Chromium.