[css-text-3] overflow-wrap: break-spaces can effect behavior even when there are previous breaking opportunities in the line

[litherum]

https://drafts.csswg.org/css-text-3/#propdef-overflow-wrap

overflow-wrap: break-word says:

An otherwise unbreakable sequence of characters may be broken at an arbitrary point if there are no otherwise-acceptable break points in the line.

overflow-wrap: break-spaces says:

Any sequence of preserved white space ... must be broken ... before the first space in the sequence if none would fit and both break-word and break-spaces are specified.

Then, there's a note that says:

This last clause is due to the fact that 'overflow-wrap: break-words'' allows breaks between any two characters to avoid overflow

But this isn't quite right. break-word only kicks in when there are no otherwise-acceptable break points in the line, but break-spaces applies in all situations.

Consider the following example, styled with white-space: pre-wrap; overflow-wrap: break-word break-spaces, where the square represents a space character:

In this situation, break-word is irrelevant, so it seems that there should be a line break before the word "text".

However, in this example:

break-word kicks in, and would find the breaking position between the "t" and the space character, so it seems that the string should break between these characters.

[litherum]

I guess my proposal would be to remove the clause:

or before the first space in the sequence if none would fit and both break-word and break-spaces are specified.

and remove the note, and let the behavior described in the note fall out of the existing behavior of break-word.

[frivoal]

In the absence of break-spaces, break-word is expected not to break before the first space of the preserved sequence at the end of the line, as it is supposed to hang (or to be collapsed, but that's already ruled out in this case, see below). If we remove the bit you suggest we remove, then what cause the requirement to change from "hang" to "break before the first space"?

We have:

• in 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.

• in https://drafts.csswg.org/css-text-3/#white-space-phase-2

  If spaces or tabs at the end of a line are non-collapsible but have white-space set to pre-wrap the UA must either hang the white space or visually collapse the character advance widths of any overflowing spaces such that they don’t take up space in the line. However, if overflow-wrap is set to break-spaces, collapsing their advance width is not allowed, as this would prevent the preserved spaces from wrapping.

If we removed the thing you said we should remove, I am worried that the following interpretation becomes either the only possible one, or a possible ambiguity:

• white-space is pre-wrap, therefore per 4.1.1's second bullet sequences of white spaces are turned into sequences of of non-breaking spaces with a wrap opportunity at the end, but not elsewhere (and specifically, not at the beginning).
• white-space is pre-wrap and overflow-wrap has break-spaces, so per 4.1.3 point 4, I cannot collapse the end-of-line preserved spaces, and must instead hang them.
• white-space is pre-wrap and overflow-wrap has break-spaces, so per the definition of break-spaces, in addition to soft wrap opportunity at the end of the sequence given by 4.1.1, there are also opportunities between each of the spaces, but since the break-spaces no longer (per your suggestion) explicitly allows breaks before the first space in the preserved sequence that space character should just be hanging, (as per 4.1.3.), and we break after that space (as per the definition of break-spaces).

With all that said, I agree that this whole thing is hard to follow, and that being sure of exactly what behavior is expected by the interaction of this various parts is quite hard, and also that the note itself may not be terribly well phrased.

So I support rephrasing either the normative text, or the note, or both, but I don't think the simple removal you suggest actually works out well.

[litherum]

I think I understand everything you said, but I'm missing the problem.

Let's consider this situation, where the square represents a space character and green represents the width of the container.

According to the current spec text,

• If this is styled with white-space: pre-wrap; overflow-wrap: break-spaces, then there would be a line break between the last space and the second-to-last space
• If this is instead styled with white-space: pre-wrap; overflow-wrap: break-word break-spaces, then there would be a line break just after the word "text" (before the second-to-last space).

The only difference between these two sets of styles is the addition of overflow-wrap: break-word. However, overflow-wrap: break-word shouldn't cause any behavior change, because white space exists earlier in the line.

My suggestion would be to change the behavior of white-space: pre-wrap; overflow-wrap: break-word break-spaces to make the line break occur between the last space and the second-to-last space.

Do you think you could be more explicit about the problem this raises?

[frivoal]

Ok, now I understand what you're talking about.

I am not sure I understand why you want that change though. Can you elaborate on "overflow-wrap: break-word shouldn't cause any behavior change, because white space exists earlier in the line."

From my point of view, there's are many variations that different people can want in different contexts, and the current syntax seemed to me that it enabled all the ones I knew about.

In particular, the variation you seem to want to get rid of (break between t and the first space) is the one that matches command line / terminals / vi and similar things.

That said, this was introduced before line-break:anywhere existed, and maybe now that is sufficient to cover this use case.

In other words, if white-space: pre-wrap; overflow-wrap: break-spaces; line-break:anywhere does breaks between the t and space in your example, then I'd probably be OK if white-space: pre-wrap; overflow-wrap: break-word break-spaces didn't.

I'm not sure I 100% understand why you'd want to change it this way (and how you'd update the text to make it go that way), but I'd probably be OK with it.

[fantasai]

line-break: anywhere allows breaks between spaces (between any two characters, in fact) so should solve the terminal-style breaking use case.

[fantasai]

Tangential analysis: https://lists.w3.org/Archives/Public/www-archive/2018Mar/0002.html