- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Thu, 17 Feb 2022 22:07:32 +0000
- To: public-css-archive@w3.org
My personal read on this issue is that there is a lot more research and development to be done here, and that it's premature to build this into CSS. If we just added a value to "turn this on", each implementation will break *substantially* differently as it tries to find what "natural line breaking" is for any given language, and we'd end up locked into one particular algorithm as Web compat builds on whatever implementations came first, regardless of what is actually more "natural". And minority languages will suffer the worst mistakes. Line-breaking has significant impact on layout, especially if we're working with higher-level, and therefore larger, constructs. Non-interop across implementations or across time can create real breakage. Instead, I'd like to see the `wrap-*` properties implemented so that they can be used by server-side and JS libraries, which allows for a lot more experimentation. Or we could add an API that allows the page to provide a JS library to apply additional line-breaking restrictions on top of the default set, if we don't want to touch the markup. Then down the line if these libraries end up converging on a set of common behaviors, we can consider standardizing those, language by language. Yes, this is more heavyweight on a given page than a native browser implementation. But it avoids locking us into compat restrictions that prevent any improvement in the feature once deployed. For something that depends on linguistic analysis, which is full of constantly improving heuristics, I think it's important not to get locked in. It's OK if a page chooses a library that it deems good enough. It's a problem if the browser chooses a library that, in the context of all the world's content, is not good enough. CC @litherum -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6730#issuecomment-1043519562 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 17 February 2022 22:07:34 UTC