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

> > Do you have any example sites/applications that do all (a)-(e)?
> 
> Offline: The "Notes" application on OS X has all of (a) to (e)
> 
> Do you mean Notes.app? I see Notes.app does the same as Chrome; i.e., not (b) nor (e). What are we seeing differently? I'm running 10.11.

Yes, I mean Notes.app. I'm on OS X 10.10.5 if it makes a difference.

Based on this example, I find that it does all of a to e.

http://florian.rivoal.net/csswg/wrap/notes-app.png

In what way does it not do that?

> Online:
> Every textarea on the web is (a)+(b)+(c)+(d) when viewed in FF or IE or Edge (unless they've overridden the default value of word-wrap to normal, which most don't). Maybe I'm just weird for wanting (e) as well, but it seems just nicer to me. As I said earlier, I'm ok with dropping that requirement or making it a quality of implementation question if that's what we're blocking on.
> 
> As far as I tried textarea on IE/FF, I see white-space wrapping only when there's no break opportunities in the line. Is that what you're referring to? It is different from what you asked.

That's the difference between having (e) or not. As I said, I prefer when we have it, but I'm OK if we don't. Do you see this being different from what I said in another way?

> Also, I haven't tested whether it's the behavior only for contenteditable/textarea or normal rendering. Have you?

Yes.

> If it's only for contenteditable/textarea,

It's not.

> it's probably more appropriate to define in Editing TF.

The Editing TF is an appropriate place to discuss how the DOM can be modified, what sort of user input cause what to happen, what sorts of events should be fired, or what sort of APIs should be available. It is not an appropriate place to discuss how a given DOM should be laid out. That's for the CSSWG (even if the editing TF may very well have interesting use cases to submit to us).

> One more thing I tested[1]; so the behavior on IE/FF is only for textarea, not for normal div, nor for contenteditable.
> [1] http://output.jsbin.com/lopave/ <http://output.jsbin.com/lopave/>
You forgot "word-wrap: break-word;" It's in the UA stylesheet for textareas, but not for divs. If you put it in, FF gives the same behavior on textareas and divs. IE doesn't.


And if you also add: "word-break:break-all" you get the behavior you described as your favorite one for code editors and terminals.

> Since we're not trying to standardize the editing behavior of textarea (are we?) I still have difficulty to understand what user problem you're trying to solve.

You asked for examples of a behavior I find acceptable. I gave you textareas in FF and IE. Given the how common textareas are, and the market share of IE and FF, that makes it an enormously common behavior.

This behavior cannot interoperably be turned on with CSS, on textareas or otherwise. I think it (or something close to it) should.

> Another case online with something very close to behavior a+b+c+d+e is what you get on contentEdtiable=true WITHOUT white-space:pre-wrap in Chrome. It's a messy behavior due to the &nbsp; shenanigans it's going through, but it approximates a+b+c+d+e, giving more evidence that it is a desirable mode.
> 
> I see it quite different from a+b+c+d+e...

In what way?

Based on this screenshot, I find it has the same a+b+c+d+e behavior as Notes.app above (with some instability due to the &nbsp; shenanigans, not visible in this screenshot).

http://florian.rivoal.net/csswg/wrap/chrome-ce.png

> What you want to solve [...]

I want default or opt-in a+b, plus sensible line breaking. I'm open to discussion on what is sensible, and on different use cases calling for different variants, although I have preferences.

I've tried to explain multiple times (many mails, some short, some long, multiple conf calls, f2f...) what I want to solve and why, but it seems I'm not getting my point across, so let's try another angle. Since you're reopening the case after we had a WG resolution, can you clarify what your goal is?

 - Florian