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

# 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
>
>
>