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

Hi,

## I want a mode where:
(a) - All spaces are preserved (i.e. taking space, can take decorations, etc) ...

(b) - ... and wrapped when they would go beyond the end of the line. (i.e. not overflowing) 

(c) - words that cannot fit a line are broken arbitrarily in the middle.

(d) - words are not broken arbitrarily in the middle when they can fit in a line, like they are with word-break:break-all.

(e) - If the only thing that makes a line overflow is spaces after a word, break in the spaces, not before the word.

## Illustrations: 

(a) means that "foo____" in a 5 letter long line gives:
  |foo__|
  |__   |
or (but see next point)
  |foo__|__
  |     |
but not 
  |foo__|


Assuming you have (a), (b) means that "foo____" in a 5 letter long line gives:
  |foo__|
  |__   |
not
  |foo__|__
  |     |


(c) means that "foobar" in a 5 letter long line gives:
  |fooba|
  |r    |
not
  |fooba|r


(d) means "foo_bar" in a 5 letter long line gives
  |foo_ |
  |bar  |
not
  |foo_b|
  |ar   |


(e) means that "fo_fo__foo" in a 6 letter long line gives
  |fo_fo_|
  |_foo  |
not
  |fo_   |
  |fo__  |
  |foo   |


## The motivations are:

a: makes spaces non magic and therefore easy to edit (pressing the space bar always does something visible, your caret cannot be in the middle of a collapsed run of spaces where you cannot see its position or cannot click on it...)

b and c : in editing contexts overflowing sucks. We need a mode where if the only choice is between breaking or overflowing, you should break, regardless of what you're breaking. 

d: just because I want non magic behavior on white space does not mean I'm interested in nonsensical breaks in the middle of words when that can be avoided, and if I wanted that, there's word-break:break-all.

e: keeps things from taking more real estate than strictly necessary.

## Additional thoughts:

* (e) is less important than the rest, and maybe it can be optional and up to the UA, or a separate switch
* Firefox does this (expect for e) when you do white-space:pre-wrap and word-wrap:break-word
* IE does this (expect for e) only inside textarea elements when you do white-space:pre-wrap and word-wrap:break-word; 
* I'm ok with other modes existing
* I'm ok with this mode not being the default
* If we want to pick a single default mode (which we don't have to), what IE/Edge does on elements other than textareas or on all elements when word-wrap is normal looks good to me.


## Which property could be appropriate for that:

word-break:break-all vs word-break:normal controls (d), and as currently resolved/written does not trigger anything else afaict. 

Overflow-wrap:break-word is designed to do "break anywhere if you have do, but don't overflow". It explicitly triggers behavior (c), but it is ambiguous whether it should also trigger (b) because it does not define what a word is. I believe it ought to. In Firefox it does b and c. In IE/Edge inside textareas it also does. In IE/Edge on other elements it does not, and for webkit/blink, we can't tell, because unlike other browsers, they don't do (a), so there are no spaces to be wrapped or to overflow.

I think we should be explicit that if a UA does (a), Overflow-wrap:break-word must do (b) in addition to (c). That seems to make sense regardless of whether we get the rest.

If we do that, the remaining open points are: how can you get (a)? How can you get (e)?

I suggested that that (a) is recommended but optional if overflow-wrap is normal, but required if overflow-wrap is break-word. The reason for that is that point of not doing a is to avoid overflow. If we have overflow-wrap:break-word, we know we won't overflow, so we can safely do (a). I'm not opposed to having it be controlled by a separate switch, but I don't see that switch as independently useful, which is why I am not proposing it.

Likewise, not doing (e) is to avoid overflow. If we have overflow-wrap:break-word, then we can safely do it since there will not be overflow. I'd like to recommend it, but I'm ok with not requiring it, or even dropping it altogether if everybody hates it.

My understanding of what Fantasai and Koji have been suggesting is either to use word-break:break-all to trigger b+d+e or  that we introduce something like word-break:break-spaces instead, which would in effect trigger (b) and (e). While that would work, I don't see why it would be more appropriate for that to trigger (a) than for overflow-wrap:break-word, and if it doesn't, it's useless in browsers than don't do (a) normally.

We could require (a) if either overflow-wrap or word-break are not "normal", in effect saying that UAs are only allowed discard trailing spaces if we're in a mode where overflow-due-to-trailing-spaces is possible. If it is not, they must do (a).

 - Florian


> On 18 Nov 2015, at 13:08, Koji Ishii <kojiishi@gmail.com> wrote:
> 
> # replied to wrong thread, back here
> 
> Thank you for filling in. The behavior you want is "b", correct? Let's not bother with what UA does today, I want to understand what you want.
> 
> From your expected results, I think what you want is:
> 1. word-wrap: break-word, and
> 2. Add break opportunity before every space characters.
> 
> 1 is already possible, so the question is which property/syntax to achieve 2.
> 
> Could you explain the use case for this behavior? We talked white-space:pre can serve both normal word processors and code editors, but I failed to remember what use case you're trying to solve.
> 
> I checked word processors and editors I have but none behave what you want, so it's hard for me to imagine, it's helpful if you could explain.
> 
> /koji
> 
> 2015-11-14 3:17 GMT+09:00 Koji Ishii <kojiishi@gmail.com>:
> Ok, so as I understand from your examples, you're **not** talking about overflow in my terminology. We have a little communication problem because we use same terminologies in different meanings. Let's try other ways to discuss.
> 
> Back up a bit, at use-case level, what you want looks like Example 2 of UAX#14 Customizations[1] to me. Am I correct? At this moment, I don't care which browsers behave how, but I'd like to understand what you want.
> 
> If not, can you fill in what you expect for some more examples here[2]?
> 
> [1] http://unicode.org/reports/tr14/#Examples
> [2] https://docs.google.com/spreadsheets/d/1mPUNK4QqOLUAUcIC84XxQnm_CwPkBcDI2lIRu1FPVfw/edit?usp=sharing
> 
> /koji
> 
> 2015-11-12 22:41 GMT-08:00 Florian Rivoal <florian@rivoal.net>:
> 
> >> 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.
> >>
> > It depends on what behavior you want, but if "b" is what you want, I think it breaks existing use cases too much that it should be opt-in.
> 
> I'm ok with that (and it is what I initially proposed).
> 
> > But then this gets even harder to understand for me...so if you have:
> > AA_AA_A
> > assume "_" is a space and the width is 5, you want:
> > AA_AA_
> > A
> > (the trailing space of the 1st line overflows)
> >
> > but if you have:
> > AAAAA_A
> > you want:
> > AAAAA
> > _A
> > (the space wraps)?
> 
> No, I do not expect the space to wrap in the second but not the first example.
> 
> Can I change your example a little for behavior "b"? It makes things easier to explain.
> I'm switching to AA_AA__A and AAAAA__A (same as you, but with 2 spaces rather than one before the last A).
> 
> behavior "d" gets you
> 
> |AA_AA|__
> |A    |
> 
> and
> 
> |AAAAA|__
> |A    |
> 
> Or with width 6:
> 
> |AA_AA_|_
> |A     |
> 
> and
> 
> |AAAAA_|_
> |A     |
> 
> Behavior "b" with width 6 gets you:
> 
> |AA_AA_|
> |_A    |
> 
> and
> 
> |AAAAA_|
> |_A    |
> 
> 
> Still in mode "b width width 5, we're in a special case, and we need to know if we allow wrapping before the first space or not. I think we should, but you and Elika have said (if I understood you correctly) that you don't, and I do not have a particularly strong opinion on that one. If we do allow wrapping before the first space, we'd get this:
> 
> |AA_AA|
> |__A  |
> 
> and
> 
> |AAAAA|
> |__A  |
> 
> If we don't, we get this on the first example:
> 
> |AA_  |
> |AA__A|
> 
> and on the second example we're kind of stuck, so we probably have to break before the space anyway:
> 
> |AAAAA|
> |__A  |
> 
>  - Florian
> 
>

Received on Thursday, 19 November 2015 04:48:02 UTC