W3C home > Mailing lists > Public > www-style@w3.org > November 2015

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

From: Koji Ishii <kojiishi@gmail.com>
Date: Thu, 19 Nov 2015 20:26:01 +0900
Message-ID: <CAN9ydbWpwAhe2tK9B3H8Vqa9G0Xj-b55vbWQJdfHOp_ybULmOg@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
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.

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

Received on Thursday, 19 November 2015 11:26:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC