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

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

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 11 Mar 2015 10:20:19 +1300
Message-ID: <CAOp6jLYdvXbUnFFouufzTNx5DsWJG_RdVv7ghWqcdiTFOkfgLg@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: www-style list <www-style@w3.org>
On Wed, Mar 11, 2015 at 9:39 AM, Florian Rivoal <florian@rivoal.net> wrote:

> While I initially found it odd as well, if you try the same thing in MS
> word or Libreoffice or Apple Pages or Apple TextEdit, the same thing
> happens. Now, we don't have to imitate other software if they are lousy,
> but it is notable that they all do the same here.

For sure LibreOffice cloned Word (that's more or less their mission
statement...). It seems probable the Apple Pages and TextEdit also did, and
Webkit cloned TextEdit.

Personally as long as you're not wrapping the collapsed space, I like the
> Firefox / IE / spec behavior just fine. However, the way Chrome & Safari
> deviate from the spec seems to be a careful match of the traditional word
> processor model rather than a random accident. Anyone from webkit or blink
> wants to chime in? If webkit & blink are happy to change to match the
> current spec, I'm all for putting this issue to rest, but if not I'd rather
> get interop, and if there's a strong argument for the webkit/blink
> behavior...

Yeah, I'd like to hear such an argument if there is one, but in the
absence, I'd go with the simpler model that doesn't put you in a situation
where the user types characters and nothing seems to happen.

But now that I have noticed and looked closer, it turns out that this
> behavior isn't exactly the same as the one you'd expect from traditional
> plain text editors. Given
> "a  b  c" (spaces are doubled) and a box that can fit 4 characters, you
> get:
> |a   |
> |b  c|
> This makes sense given the processing model, but a more traditional
> behavior would be
> |a  b|
> |  c |
> Similarly, with "a b   c" (3 spaces after b)  and a box that can fit 4
> characters, you get:
> |a   |
> |b   |
> |c   |
> rather than
> |a b |
> |  c |
> A simple way to describe the "correct" behavior would be for every space
> in a non collapsed white space run to be rendered as an &nbsp; preceded and
> followed by zero-width-spaces (U+200B).
> Granted, the "white-space:pre-wrap;word-wrap:break-word" behavior isn't
> that far off in many cases, but it's still not quite as nice.

It seems like you want a new CSS feature that allows soft line breaks
anywhere in a sequence of whitespace characters instead of just at the end
of such a sequence.

Personally I don't know that it's worth having.
http://dev.w3.org/csswg/css-text-3/ is already looking a bit complex...

oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
otohoeo ofoioroeo ooofo ohoeololo.
Received on Tuesday, 10 March 2015 21:20:51 UTC

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