- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Wed, 11 Mar 2015 10:20:19 +1300
- To: Florian Rivoal <florian@rivoal.net>
- Cc: www-style list <www-style@w3.org>
- Message-ID: <CAOp6jLYdvXbUnFFouufzTNx5DsWJG_RdVv7ghWqcdiTFOkfgLg@mail.gmail.com>
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 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... Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Received on Tuesday, 10 March 2015 21:20:51 UTC