Re: [csswg-drafts] [css-text-3] Implement or unship word-break:break-word

> Examples should always better describe problem

Examples illustrate the problem, and are great together with a explanation to make sure there is no misunderstanding, but they are rarely enough.

> I just don't see real reason to deffer it.

Defer means no work. Define now means work. Deferring is the normal answer until enough people are convinced it is needed, either for compatibility reasons or because it is useful.

You are trying to convince a large group of people to do work (write the spec, write the tests, write the code, forever maintain them and take them into account when designing new features). Spending time explaining why that matters is usually more effective than hoping everyone will independently come to the same conclusion.

> [in addition] to overflow-wrap: break-word, it is computing min-content inline size as [if `word-break` was `break-all`].

I understand that this is what it does. I was wondering if you could explain why that is important. Not because I do not believe you, but because explaining why is this best way to help convince the group that this is important enough to warrant the effort, and to evaluate the solution. I can come up with an explanation, but I would prefer to hear from you why you think it is important, instead of guessing your motivations.

You may want to have a look at this description of [the best way to propose features](https://whatwg.org/faq#adding-new-features). It was written for a different working group, but is generally applicable here. It is not a formal process that we have to follow, but it is good advice in terms of convincing a web standards working group to solve a problem you have. "please add this feature" is step 8.

In order to keep CSS maintainable, even when convinced that a problem is worth solving, the group usually wants to consider whether a particular approach is the best way to solve the problem, or whether some other solution would be better.

For example, to solve this problem, I can think of several solutions (not saying they are equally good):
1. `word-break: break-word` as currently implemented in chrome
2. a new value to `overflow-wrap` that makes it affect intrinsic sizing. e.g. `overflow-wrap: break-word` vs `overflow-wrap: break-word allow-shrink`.
3. a new value to `white-space` that changes how intrinsic sizing is calculated. e.g. `white-space: normal` vs `white-space: normal allow-shrink`.
4. A new property to directly affect intrinsic sizing. e.g. `min-content-width: 0`
5. A new table-specific property. e.g. `table-cell-wrap: auto | aggressive`

Solution 1 has the advantage of already existing in some browsers and in some content. It has the disadvantage of making a confusingly named set of properties and values even more confusing, and of lacking the additional flexibility offered by solution 2, 3 or 4. Maybe it matters, maybe it does not.

Solution 2 have the advantage that it can be combined with other values of the `word-break` property, which may be better for internationalization purposes. Since the other values of the `word-break` property are primarily about supporting good typography in Chinese, Japanese and Korean, this may be a good thing. Korean authors may want to use it together with `word-break: keep-all`, Japanese or Chinese authors may want to use it together with `word-break: break-all`.

Solution 3 is similar to solution 2. An additional advantage is that you can use it without setting `overflow-wrap: break-word` if you are interested in the sizing effect but not the wrapping effect and prefer to overflow. A disadvantage is that you need to set more properties if you do want both effects, and that it would not work in table cells without setting both, since table cells cannot overflow.

Solution 4, like solution 3, has the advantage that you can get the sizing effect without the wrapping effect if you want to and to work with all the values of `word-break`, and the same disadvantage of not working in table cells unless you also set has `overflow-wrap: break-word`. It also has the advantage that it can be used in many other different contexts, even when not related to text-wrapping: for example, you could use it to change the intrinsic size of images. This however has the disadvantage that it sets the minimum size to 0, instead of to the widest letter, as `word-break:break-word` would do. Maybe this matters, maybe it doesn't. Maybe making this generic is great, maybe it is overkill.

Solution 5 may be better if the actual problem is limited to text within tables, and if we don't want to make a generic solution to a narrow problem.

But listing solutions is  suggested as "step 5" in the above process, because getting a list of detailed requirements is very helpful to chose between the various possible solutions.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2390#issuecomment-381862411 using your GitHub account

Received on Tuesday, 17 April 2018 06:29:40 UTC