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

2015-11-19 17:56 GMT+09:00 Florian Rivoal <florian@rivoal.net>:

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

(a), (b), (c), (e) are the behavior I described as "terminal" before. I've
never seen any code editors do (d), any examples?

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

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.

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.

Also, I haven't tested whether it's the behavior only for
contenteditable/textarea or normal rendering. Have you? If it's only for
contenteditable/textarea, it's probably more appropriate to define in
Editing TF.

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

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
>

So, no, I still don't see any apps/sites doing a+b+c+d+e. Do you have more
concrete examples?

Code editors ('terminal') maybe theoretically nice to support, but I'm not
hearing requests from code editor developers nor users of browser-based
code editors, so I'm not in hurry to add them until they speak up.

What you want to solve is word processor use case, correct?

/koji