- From: Myles C. Maxfield via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Jun 2023 20:07:55 +0000
- To: public-css-archive@w3.org
To be clear, the implementation I’ve been discussing is part of the platform, being applied across the OS. > For Japanese, the need is typically expressed as wanting line breaks at phrase segment boundaries (文節に / よる / 改行を / 行う), not word boundaries (文節 / に / よる / 改行 / を / 行う), though we may want both modes to let authors pick, depending on context. This could be addressed by two keywords (word-break: […] | auto-words | auto-phrase). Or maybe we don't give a choice, and that's just a quality of implementation question. Right, titling this issue to be about “words” was a poor choice of … words. You’re right that phrases the right granularity here. Our current architecture is designed to handle phrases no problem. Therefore, this shouldn’t be an author choice, and we shouldn’t be adding 2 new values. > Authors might want to conditionally apply some other styles when this works, for example justification. I think this is another argument we should be adding a new value, so that @supports works. Also, yet another argument in favor of a new value: I don’t want to hook this up to an existing property, and then discover that it created a performance regression in our multilingual benchmarks. The best way to avoid a regression is to have this be opt-in, via a new value. -- GitHub Notification of comment by litherum Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8920#issuecomment-1579375859 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 June 2023 20:07:57 UTC