[css-text] A single leading white-space should prevent word breaking honoring white-space: pre-wrap #2907
Description
Lets considering this simple test case:
<!DOCTYPE html>
<style>
div {
font-family: Ahem;
font-size: 20px;
line-height: 1;
white-space: pre-wrap;
width: 2ch;
border: 2px solid blue;
}
.ch1 {
width: 1ch;
}
.break-all {
word-break: break-all;
border-color: red;
}
.break-word {
word-wrap: break-word;
border-color: orange;
}
.break-break-word {
word-break: break-word;
border-color: purple;
}
</style>
<div> xx</div>
<div class="ch1"> xx</div>
<div class="break-word"> xx</div>
<div class="ch1 break-word"> xx</div>
<div class="break-break-word"> xx</div>
<div class="ch1 break-break-word"> xx</div>
<div class="break-all"> xx</div>
<div class="ch1 break-all"> xx</div>
The spec prose about the pre-wrap value is clear in this case:
https://drafts.csswg.org/css-text-3/#white-space-phase-1
If white-space is set to pre or pre-wrap, any sequence of spaces is treated as a sequence of non-breaking spaces. However, a soft wrap opportunity exists at the end of the sequence.
So, we got, as expected, the same result in all lf the major browsers:
| Case 1.1: <div> xx</div> | ||||
| Chorme | Firefox | Safari | Edge | |
 |
|
|
| |
| Case 1.2: <div class="ch1"> xx</div> | ||||
| Chorme | Firefox | Safari | Edge | |
 |
|
|
| |
If we use the word-wrap: break-word in combination with the pre-wrap, we introduce additional breaking opportunities to avoid the overflow:
| Case 2.1: <div class="break-word"> xx</div> | ||||
| Chorme | Firefox | Safari | Edge | |
 |
 |
|
| |
| Case 2.2: <div class="ch1 break-word"> xx</div> | ||||
| Chorme | Firefox | Safari | Edge | |
 |
|
|
| |
Chrome diverges from the behavior the rest of the browsers follow in the case 2.1. I think it's a clear bug, since the leading white-space is an actual breaking opportunity that avoids the overflow, hence, no need to apply the word-wrap property in this case, which will imply breaking the word. In the case 2.2, though, all the browsers are interoperable and there is no way to avoid breaking the word. I'd like to remark that all of them apply the pre-wrap value and breaks in the leading white-space.
I think there are no doubts, so far, but lets consider now what would happen if we use the work-break property instead of the word-wrap. As far as I understand, the word-wrap property is applied after considering all the breaking opportunities, and only in the case that the word still overflows, we can apply the additional line-breaking opportunities, depending on the specific value of the word-wrap property.
However, in the case of the word-break property, the new breaking opportunities must be evaluated at the same time than the ones provided by the white-space property. Lets consider now the case of word-break: break-word; this is how each browser behaves in this case:
| Case 3.1: <div class="break-break-word"> xx</div> | ||||
| Chorme | Firefox | Safari | Edge | |
 |
 |
|
| |
| Case 3.2: <div class="ch1 break-break-word"> xx</div> | ||||
| Chorme | Firefox | Safari | Edge | |
 |
 |
|
| |
Chrome also diverges in Case 3.1 from the rest of the browsers; however, Firefox and Edge don't implement the break-word value, since it was removed in the last draft of the CSS Text spec. Hence, the comparison is only valid with Safari, which I think implements the right behavior. As it was commented in Case 2.1, the word shouldn't be broken if there are other breaking opportunities before, in this case, the leading white-space. This is also the default behavior applied by Firefox and Edge since they parse the break-word as invalid.
Finally, lets evaluate what happens if we use word-break: break-all value, which is still defined in the last draft of the spec and indeed implemented by all the browsers:
| Case 4.1: <div class="break-all"> xx</div> | ||||
| Chorme | Firefox | Safari | Edge | |
 |
|
 |
| |
| Case 4.2: <div class="ch1 break-all"> xx</div> | ||||
| Chorme | Firefox | Safari | Edge | |
 |
 |
|
| |
Only Safari shows a different behavior in Case 4.1, which uses the leading white-spaces as priority breaking opportunity, so it doesn't need to break the word. As it was commented before, I think this is the correct and most coherent behavior; I don't see why we need to break the word if it's not necessary.
The case 4.2 is different, since even breaking at the leading white-space, there is no enough space for the word, hence, honoring the break-all value, the word is broken to avoid the overflow. Chrome is diverging in this case and it actually lead to overflow, which I think it's incorrect because it's perfectly avoidable.
The following table describes my proposal for each of the cases analyzed before:
| Case 1.1 | Case 1.2 | Case 2.1 | Case 2.2 | Case 3.1 | Case 3.2 | Case 4.1 | Case 4.2 |
| pre-wrap | pre-wrap+word-wrap | pre-wrap+break-word | pre-wrap+break-all | ||||
|
|
|
|
|
|
|
|
My proposal matches Safaris's behavior in all the cases and it basically avoids to break the word in any case if there are other soft-breaking opportunities before.