- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Jun 2023 07:27:33 +0000
- To: public-css-archive@w3.org
> I honestly don’t understand the backwards-compatibility story described above in this thread. If a publishing house cares very much about exactly where their line breaks are, they won’t use this property, because different browsers and OSes will implement it differently. Therefore, it’s totally OK if this property has progressive enhancement; the author doesn’t know where the line breaks will be anyway - they are just telling the browser “do your best to improve the quality, possibly at the expense of performance.” I think this is a sign that this should not be on a dedicated property, and that it does belong as a special value of `word-break`. Indeed, as a special value of `word-break`, as you said, if the browser doesn't know how to do the detection for the given language, it falls back to normal line breaking, and that's fine. If it is a value on a separate property with the behavior proposed for `word-boundary-detection` there is a problem to be solved. I now think it is the wrong solution, but there was a problem: `word-boundary-detection` doesn't make words stay together on their own, it merely introduces `<wbr>` equivalents where the boundaries belong, and counts on the author separately turning on `word-break: keep-all` to get the correct line breaking. But if `keep-all` gets turned on on a piece of text where the browser doesn't know how to detect the boundaries, then instead of falling back to normal line breaking, you fallback to just `keep-all`, which means mostly no breaking at all. There was a reason for having it as a separate property (the injected boundaries can be used for other purposes), but still, the awkwardness of this language parameter show that this is likely the wrong design. refactoring this into a new `word-break` value (and rearanging `word-boundary-expansion` to work differently) will work better. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7193#issuecomment-1586742941 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 June 2023 07:27:35 UTC