Re: [css-text] white-space: pre-wrap

>>> 2. The resolved behavior would give you a bit strange experience if a word ends at the right margin, then you'd see the space character on the beginning of the next line. Are we sure we want this behavior?
>> 
>> I think so. The author asked for preserve and wrap, that's what he gets. For "smart" perserve and wrap, allowing UAs to decide what to do about spaces left at the end of the line, you can use the pre-wrap-auto value instead.
>> 
>> And if the author wants to be explicit (rather than automagic) about removing spaces at the end of the line, there's the pre-wrap-trim value to be added in level 4 (I'll send a pull request about this shortly).
> 
> Preserving is fine, I agree, but can you share in what use cases who asked to wrap before a space character?
> 
> Take an example: "hello world" and it hits right margin after "o". You will then see a space at the beginning of the 2nd line.
> 
> So to re-word my question, break between SP + SP is ok, but I wonder whether AL + SP makes sense or not, and whether this is intentional?

The main point of the F2F discussion was SP+SP. Whether AL+SP should be a special case was briefly mentioned during the discussion, and we prefered keep the model simple and predictable. I think that's particularly valuable in editable text fields using pre-wrap: whenever you press space, you visibly insert a space, if there was room on the line, then it goes there. If there is not, it goes to the next line. That makes editing much more predictable and understandable.

When you're not in an editing context, it is a bit more debatable, but white-space: pre-wrap is typically not applied to ordinary prose, but rather to content where white-space is significant. And in that case, I'd argue that breaking before the space is still the right thing to do.

The alternatives I can think of are:
1.a- disallow breaks between AL+SP when there's a single space
1.b- disallow breaks between AL+SP when there's any number of spaces
2.a- collapse to 0 the advance with of a single SP in AL+SP when it would cause line breaking or overflow
2.b- collapse to 0 the advance with of the first of any number of SP  in AL+SP when it would cause line breaking or overflow

(for more variants, replace AL with "any non SP character" in the definitions above, or replace "collapse to 0" with "treat as if collapsed to 0 for the purpose of line breaking").

I think 1.a and 2.a are weird, especially in editing contexts, as adding more spaces after the first one would make the first one behave differently, and that's counter intuitive.

2.b seems preferable to 1.b because if you have "Hey, Hello world" with the break falling after hello's o, this
  |Hey, hello|
  |world     |
is certainly nicer than that:
  |Hey,      |
  |hello     |
  |world     |

But then again, given that the author is explicitly styling the content not as regular prose, but as something where whitespace is significant and should be preserved, is it actually better than what's currently in the spec? I am not convinced.

 - Florian

Received on Thursday, 24 September 2015 07:13:39 UTC