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: Thu, 12 Mar 2015 13:26:49 +1300
Message-ID: <CAOp6jLZe1_q6yK6UA5Fga4W4o+qzJJaByeJOLa_YPBebWdfxAw@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style <www-style@w3.org>
On Thu, Mar 12, 2015 at 5:08 AM, fantasai <fantasai.lists@inkedblade.net>
wrote:

> On 03/09/2015 07:34 PM, Florian Rivoal wrote:
>
>> TL;DR: there is not full interop on what happens to longer-than-the-line
>> sequences of white space under "white-space: pre-wrap", nor is it obvious
>> that there is a single desirable behavior. There's probably 2, both
>> different from what the spec currently says, and I want a switch.
>>
>> === Intro
>> "white-space:pre-wrap;" (or equivalently with level 4 properties
>> "text-space-collapse: preserve; text-wrap: normal;") prevents runs of white
>> space from being collapsed into a single space character. It does so based
>> on the white space processing rules (http://dev.w3.org/csswg/css-
>> text-3/#white-space-rules), which state:
>>
>>    If white-space is set to pre-wrap,
>>    any sequence of spaces is treated
>>    as a sequence of non-breaking spaces.
>>    However, a soft wrap opportunity
>>    exists at the end of the sequence.
>>
>> While this generally works, one effect is that a sequence of white space
>> longer than the line will overflow the line, rather than wrap.
>>
>> === Problem number 1:
>> Chrome & Safari do something slightly different. Compare this in
>> IE/Firefox vs Chrome/Safari:
>> http://jsbin.com/hakalu/1/watch?html,css,output
>>
>> All agree that the long sequence of white space should not wrap to the
>> next line. However, only IE & Firefox do what the spec say and let the line
>> overflow. Chrome & Safari truncate excess white space instead of
>> overflowing.
>>
>> While this seems to be a spec violation, it matches the behavior of
>> traditional word processors / rich text editors like MS Word, Apple
>> TextEdit (in rich text mode), LibreOffice, KWrite, Kate... So I wouldn't be
>> to quick to call it a bug.
>>
>
> This is valid per spec, see
>   http://dev.w3.org/csswg/css-text/#white-space-phase-2
>   bullet #4
>


That text is a bit ambiguous. At first reading I would interpret "visually
collapse their character advance widths" as meaning "set their character
advance widths to zero", but the Webkit/Blink behavior is more like "reduce
their character advance widths to any value >= 0".

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 Thursday, 12 March 2015 00:27:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC