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

On Thu, Sep 24, 2015 at 4:13 PM, Florian Rivoal <florian@rivoal.net> wrote:

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

I understand that concern. There's a request in Chrome, and I heard that
before for the word processor I worked for too. However, I think you should
keep in mind, once you wrap spaces to the beginning of next line, you will
hear complaints from other people for other use cases. It's a trade off,
neither one is really superior than the other. Decades ago I tried to solve
but failed because other people complained. It may be different this time,
but I think we should really think about downsides too.

I'm actually surprised how well Trident solved this problem. It's an idea
I've never thought about, but I see a good possibility in it. What part of
the Trident behavior did the WG not like?

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

White-space is significant for any word processors and text editors except
HTML/CSS, and there are a lot of word processors and text editors that
overflow spaces at the line end. When people see the specific case, I
understand we want to fix that, but the overall the behavior is what users
expect.

To me, having spaces at the beginning of lines look more odd, it's like
console or simple plain text editors.

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

Changing behavior by the number of spaces is probably a bad idea, let's not
do that.

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

I don't really understand 2.b.

But my general preference is if you want to change the line breaking
behavior, do it in properties like word-break. I believe "pre-wrap" is
understood to authors that it's "no collapse + normal wrap."

Have we made any assessments how much this is safe for web-compat?

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

Again, I think you're trapped too much in HTML/CSS. Collapsing white-spaces
is the special behavior for authoring HTML source files, and "pre-wrap"
makes UA to a regular state, so I think we should make it a regular
behavior.

/koji