Re: [css-text] pre-wrap / pre-wrap-auto

> On 10 Nov 2015, at 19:02, Koji Ishii <kojiishi@gmail.com> wrote:
> 
> 2015-11-09 20:46 GMT-08:00 Florian Rivoal <florian@rivoal.net <mailto:florian@rivoal.net>>:
> 
> But anyway, yes, adding a switch was my initial proposal, and the way I recall the discussion, the conclusion was that
> if that's the behavior we want, let's have it by default rather than opt-in.
> 
> If the new behavior does not serve use cases current behavior does, it should be opt-in.

My opinion is that we need at least the new behavior ("b"). Whether it can also work for the use cases served by the current behaviors, I have a less strong opinion about. The NY F2F concluded that it mostly could as long as we made the new pre-wrap-auto value available for UAs to put in the UA stylesheet, but I'm fine going the other way, and have behavior "b" be an opt-in.

>> Two things I think we would need consensus on:
>> 
>> 1. Assuming this is a code editor use case, I still believe any editors that wraps before space also wraps in the mid of words. Visual Studio, NotePad, TextEdit do so. On the other hand, Atom does not wrap in the mid of words but does not wrap before space either. Having an example of "wrap before space but not mid of words" would be helpful if you want this combination.
> 
> Agree on having 2 different behaviors. I'm proposing to trigger the first one with overflow-wrap: break-word, and the other one with a new value, overflow-wrap: break-spaces.
> 
> Can I confirm, are you proposing two new values, one for mid-of-words and the other for before-spaces?

Not quite. I am proposing that we clarify overflow-wrap:break-word, which is an existing value, as causing both wrapping in the middle of overflowing words and in the middle of overflowing spaces, and later introduce a new one (break-spaces?) to only break in the middle of overflowing spaces.

> I might not be clear enough, sorry about that, what I wanted to say was that, isn't one switch to turn both on enough? Do we have separate use cases where authors want to turn it on separately?

It makes sense to me to want to wrap the spaces individually but not break in the middle of words, but I'm ok deferring that to a later level, pending confirmation of use cases. I would just like to take the possibility of doing that into account when deciding which property to use to opt into these various behaviors.

>> 2. It may depends on above, but it feels me that the value should belong to word-break rather than white-space.
> 
> I think it goes into overflow-wrap (aka word-wrap) rather than word-break, but open for discussion.
> 
> overflow-wrap is only when overflow occurs (i.e., there's no other break opportunities in the line,) so what you want should be word-break.

The way I see it, "d" would be the canonical behavior, and therefore overflow would occur, justifying the use of overflow-wrap to create wrapping opportunities in the overflowing preserved spaces. "c" (and "a" if we allow it) would be an allowed variant when overflow-wrap is normal, but when you set it to break-word, UAs have to revert to "d", then the since we wrap the spaces, it becomes "b". And since overflow-wrap: word-break currently says nothing about spaces, we would not be contradicting what the spec has been saying so far, just clarifying it.

Wrapping spaces when overflow-wrap is word-break is already what FF does, and what IE/Edge do in textareas, although they do it from behavior "a", not from "d".

If this approach doesn't make sense to you, going through word-break is also a possibility. What I don't like about that is that the spec is currently explicit about word-break:break-all not affecting spaces, so we either have to change the definition to that effect (is there a compat risk?) or to introduce an additional value (meh).

 - Florian