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

> On 19 Nov 2015, at 15:44, Koji Ishii <kojiishi@gmail.com> wrote:
> 
> 2015-11-19 13:47 GMT+09:00 Florian Rivoal <florian@rivoal.net>:
> 
> ## 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.
> 
> [snip]
> 
> ## 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.
> 
> Before diving into how to design this mode, what I don't understand is what kind of applications this mode makes happy. In my understanding, code editors want (a), (b), (c), (e), but not (d).

Maybe it's a matter of personal taste, I'd prefer having d, and I am not so fussed about (e) even though I prefer having it. But at least we can agree that for a code editor you want at least (a) and (b) and (c), and probably (e) as well, right? 

> Word processors want (a), (c), (d), but not (b) and (e).

That's reasonable. Not having (a) is also done occasionally (e.g. LibreOffice Writer), and if you don't have (a) whether or not you have (b) or (e) is a nonsensical question, since you need overflowing spaces for them to make sense.

> What are the editing contexts that are not either code editors nor word processors?
Youtube comment fields, blog comment fields, reddit, mail composing windows, todo apps.... Most multiline input fields are neither rich text nor code oriented. In that case the point of having (a) is not so much that white space is significant, but rather than interaction with the editor is predictable, and as mentioned above, 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 nor reliably click on it, a selection containing multiple spaces is always visible....

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

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.

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.

Eitherway, simple text editors also require that we can get a mode where we have all of a-b-c, even if for d and e this may (or may not) be different from the code editor mode.

So these seem to be the 3 modes we want (with a ? on the non essential part of the mode, for which maybe we want a switch, or maybe we can leave it up to UAs, or maybe we can just pick one and not support the other):

* a?+c+d rich text editors
* a+b+c+e code editors
* a+b+c+d+e? simple text editors

The New York resolution allows for these 3 modes. You use pre-wrap-auto for the rich text mode, and pre-wrap for the other two, with word-break:break-all to switch (d) on or off. And in all cases, you use overflow-wrap:break-word since you want (c).

An alternative way is to have the "rich text editor" behavior as the default for pre-wrap. Then you have something else to turn that into the "simple text editor" (and you put that in the UA stytlesheet for textarea elements). Finally, when you do that thing + word-break:break-all; you get a code editor.

However, unlike what I suggested earlier, if we want "c" in the rich text editor (which seems reasonable), overflow-wrap cannot be the switch between that and the other modes, and the switch should be something else.

 - Florian

Received on Thursday, 19 November 2015 08:56:42 UTC